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1.  Executive  Overview 

1. 1.  Scope 

This  document  is  submitted  in  fulfillment  of  requirement  4.1.2,  and  CDRL  A005;  from  the 
Statement  of  Work  for  the  Peer-to-Peer  Information  System  Management  Contraet 
#F30602-96C-0049. 

1.2.  Document  Stylistic  Conventions 

This  doeument  is  published  both  in  paper  and  hypertext  formats.  Double  underlines 
represent  Hypertext  links  in  the  paper  form.  The  eross-referenees  are  identified  inline, 
external  referenees  are  eolleeted  in  an  Appendix,  On-line  References. 


1.3.  Introduction  and  Overview 

This  is  the  System  Requirements  Document  for  the  Peer  to  Peer  Information  System 
Management  program.  It  eovers  in  detail  the  eonstraints  and  requirements  identified  by  the 
RFP  SOW  or  identified  to  date  by  BBN  as  neeessary  to  develop  a  system  arehiteeture  that 
allows  SOW-required  management  information  transfer; 

1.  to  be  within  a  seeurable,  objeet-oriented  infrastrueture  that  treats  the 
eommunieating  parties  as  peers, 

2.  to  be  optimized  aeeording  to  the  information's  utilization  and  usage 
eharaeteristies. 


The  minimum  subset  of  management  information  to  be  transferred  eomprises 

1.  status  monitoring 

2.  events,  traps  and  notifieations  monitoring  and  management 

3.  eontrol  eommands 

4.  monitoring  within  an  historieal  eontext 

The  minimum  subset  of  managed  objeet  elasses  to  be  eovered  eomprises 

1.  IP  deviees 

2.  ATM  deviees. 


Some  of  the  eapabilities  will  be  supplied  by  purehased  eomponents;  other  eapabilities  will 
be  provided  by  BBN-developed  eomponents.  The  speeifieation  of  the  eomponents  and 
their  responsibilities  is  provided  in  the  Peer  to  Peer  System  Architecture  document. 
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1.4.  Related  Documents 


1.4.1.  Request  for  Proposal 

Solicitation  #  F30602-96-R-0049 


1.4.2.  BBN  Proposal 

P96-STD-395 

1.4.3.  Market  and  Technologies  Study 

BBN  Technical  Report  8180,  Nov.  1996 

A  report  of  the  results  of  a  survey  covering  the  existing  commercial  off  the  shelf  produets 
and  available  teehnologies. 

1.4.4.  System  Architecture 

A  sneeifieation  of  the  system  arehiteeture  based  on  the  Market  and  Technologies  Study 
results  and  this  Requirements  Document. 

1.4.5.  Prototype  Implementation  Plan 

A  specifieation  of  those  aspeets  and  components  of  the  system  arehiteeture  that  shall  be 
included  in  the  proof-of-coneepts  prototype  system. 


2.  Document  Status 

Delivered  to  Customer. 

Last  updated  on  05/15/97  12:34:57  PM  by  Linsev  O’Brien. 

3.  Environmental  Requirements 

The  system  shall  operate  on  or  in  conjunction  with  at  least  the  following  platforms: 

•  Solaris  2.5.1 

•  HP  Openview 

•  Tivoli  TME 


HP  Openview  was  designated  a  required  network  management  platform  by  the  REP 
Statement  of  Work  seetions  2.1  and  4.1.4.  It  is  a  legaey  objeet  oriented,  remote  network 
management  system.  It  is  not  CORBA  eompliant. 

Tivoli  TME  was  seleeted  to  be  the  second  of  two  network  management  platforms  during 
the  Market  and  Technologies  Study  .  It  was  picked  beeause  it  appeared  to  offer  a  solid, 
open  technieal  foundation  that  also  had  significant  COTS  market  share.  It  is  CORBA  1 .0 
and  MIB-II  compliant,  but  the  CORBA  framework  is  not  directly  accessible  except  under 
stiff  licensing  fees.  Technical  strategies  for  dealing  with  these  issues  are  described  in  the 
System  Arehiteeture. 
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Per  conversations  with  the  client,  Rome  Labs,  The  Peer  to  Peer  Systems  Architecture  shall 
not  be  CMIS-  or  CMIP-  based,  although  integration  with  CMIS  components  shall  not  be 
prevented. 


4.  Management  Information  Requirements 

The  following  requirements  are  the  management  information  factors  driving  the  design  of 
the  Peer  to  Peer  Network  Management  System  Architecture. 


4. 1.  Management  Application  Operations 

The  system  shall  support  integrating  significant  management  information  input  and  output 
necessary  to  coordinate  peer  management  operations.  Such  management  information  types 
included  status,  event,  and  statistical  monitoring  and  management,  and  issuing  control 
commands. 


4.1.1.  Status  Monitoring 

Status  information  is  the  heart  of  day  to  day  operations.  Monitoring  status  of  critical 
components  is  the  starting  point  for  most  management  procedures.  Integrating  two  peer 
systems'  status  information  is  primarily  a  matter  of  distributing  updates  among  peers  when 
the  status  of  monitored  components  changes.  This  may  be  done  through  several 
distribution  mechanisms:  status  polls,  event  management  and  monitoring  the  results  of 
control  operations.  Which  mechanism  is  used  depends  on  how  the  network  management 
systems  in  question  classify  the  status  information.  Integrating  those  mechanisms  is 
discussed  in  the  Usage-based  Distribution  section  below. 


4.1.2.  Event  Monitoring  and  Management 

Event  information  is  often  simply  status  change  information  and  as  such  is  distributed 
through  an  asynchronous  notification  mechanism.  It  is  included  here  as  a  distribution 
variant  of  status  monitoring.  However,  it  can  also  convey  other  information  with  similar 
distribution  characteristics. 


4.1.3.  Historical  Data  and  Trend  Monitoring 

Historical  data  are  generally  accessed  for  one  of  two  reasons: 

1.  Monitoring  in  Context:  Data  are  collected  and  analyzed  in  real  time  in  order  to 
make  network  management  decisions  regarding  routing,  whether  or  not  to  dial-up 
additional  bandwidth,  when  to  run  particular  applications,  and  so  forth.  Although 
this  function  emphasizes  current  performance,  it  is  generally  not  sufficient  to 
merely  query  and  receive  a  single  number— such  as  the  current  utilization  of  a 
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particular  link — since  such  data  are  meaningless  unless  plaeed  within  the  broader 
eontext  of  trends  and  past  performanee. 


2.  Performanee  analysis:  Data  are  eollected  and  analyzed  off-line  in  order  to  assess 
the  health  of  the  network,  do  eapaeity  planning,  bill  users,  and  so  forth.  This 
funetion  stresses  historieal  data  from  whieh  trends  and  use  patterns  must  be 
extraeted.  The  quantities  of  data  may  be  very  large,  but  their  transfer  is  not  very 
time-sensitive  sinee  performanee  analysis  is  usually  eonducted  in  bateh  mode 
during  off-peak  hours. 


In  either  ease,  there  are  both  implied  distribution  and  storage  requirements,  eovered  in  the 
Usage-based  Distribution  and  Storage  sections  below. 


4.1.4.  Control  Commands 

Control  eommands  are  what  eomplete  the  management  loop  and  while  they  are  the  most 
powerful  operations  in  the  management  system  array,  their  fundamental  distribution  and 
storage  requirements  are  trivial  subsets  of  the  monitoring  operations.  They  do  have, 
however,  signifieant  manageability  and  security  requirements  deseribed  in  the  relevant 
seetions  below. 


4.2.  Target  Components 

Monitoring  and  eontrol  operations  require  target  components  and  those  components  further 
refine  the  type  and  usage  of  the  operations  and  their  management  information. 


4.2.1.  SNMP  interfaces  to  IP  Components 

The  system  shall  allow  information  and  functions  exported  by  SNMP  V2  network 
management  systems  to  be  incorporated. 

The  system  shall  support  the  networking  MIBs  defined  aeeording  to  the  IETF  SNMP  V2 
standards  to  the  extent  that  the  peer  network  management  system  being  integrated  supports 
sueh  MIBs.  Other  MIBs,  if  defined  aeeording  to  STD  17  /  RFC  1213  or  RFC  1902,  may  be 
integrated  if  the  management  information  system  allows  MIBs  and  managed  objeet  elasses 
to  be  added. 


4.2.2.  XBind  ATM  management  interface 

The  system  shall  allow  information  and  funetions  exported  by  XBind  network 
management  systems  being  developed  at  Columbia  University  to  be  ineorporated. 
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5.  Supporting  Infrastructure  Requirements 

The  following  factors  are  requirements  derived  from  the  need  to  integrate  with  other 
existing  or  planned  technologies. 


5. 1.  Distribution 

The  primary  issue  in  integrating  peer  management  systems  is  defining  how  their 
information  distribution  systems  will  be  connected  such  that  information  from  one  system 
can  easily  and  appropriately  flow  to  one  or  more  others.  The  following  requirements  affect 
connecting  two  or  more  management  systems'  distribution  infrastructure. 


5.1.1.  Peer  to  Peer  Distribution 

The  system  shall  integrate  management  information  and  functions  from  a  variety  of 
interfaces  such  that  the  operation  of  one  management  system  shall  not  be  required  in  order 
for  the  other  to  operate.  However,  if  the  operators  of  each  system  so  allow,  one  system  can 
monitor,  control,  exchange  historical  data  with,  and  field  events  from  the  other  system.  The 
first  peer  system  integrated  shall  be  based  on  HP  Openview.  The  second  peer  system 
integrated  was  selected  as  a  part  of  the  study  phase  and  is  the  Tivoli  TME  system. 


5.1.2.  WAN  Topology 

As  networks  expand,  they  are  increasingly  having  to  interoperate  over  Wide  Area  Network 
(WAN)  boundaries  with  peer  networks.  Such  peer  networks  are  run  by  peer  organizations 
using  their  own  network  management  systems.  Peer  management  systems  are  often  not 
located  within  the  same  [extended]  LAN  because  peer  business  organizations  managed  by 
peer  but  different  management  systems  generally  do  not  share  a  LAN.  Support  for 
management  information  distribution  across  such  borders  and  WAN  gateways  is  common 
and  therefore  required. 

One  common  exception  to  this  rule  of  peer-management  situations  used  to  be  the  rule.  It 
occurs  when  a  single  organization  is  trying  to  migrate  gradually  from  one  management 
system  to  another.  Often  the  two  management  systems  are  peers  during  the  transition. 

This  was  the  most  common  peer  management  situation  when  most  networks  were 
extended  LANs.  Even  if  they  had  WAN  components  they  were  still  managed  by  a  single 
business  organization.  Given  that  the  presumption  that  one  system  was  replacing  the  other, 
the  systems  were  only  temporarily  peers,  and  market  share  was  changing  hands,  most 
network  management  vendors  opposed  peer  management  configurations  that  would  make 
it  easy  for  another  vendor  to  replace  them  and  their  customers  generally  condoned  the 
resulting  technical,  architectural  and  financial  barriers  to  such  configurations. 

Such  situations  will  continue  to  exist;  large  company  /  large  market  share  vendor 
opposition  to  peer  management  architectures  may  be  defused  by  allowing  peer 
communications  only  across  WANs.  This  will  restrict  the  potential  takeover  targets  to 
larger  organizational  groups  and  minimize  the  risk  that  a  competitor  will  gain  a  toehold. 
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As  smaller  companies  will  want  to  gain  such  a  toehold,  they  too  should  support  the  WAN 
distribution  requirement. 

A  third  driving  force  for  WAN  distribution  is  the  nature  of  ATM  equipment  management 
interfaces  (another  Peer  to  Peer  system  requirement,  see  the  section  on  XBind  /  ATM 
components  below  ).  In  many  cases  the  ATM  switches  do  not  provide  direct  interfaces  to 
the  relevant  operations  and  data  and  network  management  systems  (such  as  XBind)  export 
the  management  data.  When  such  systems  setup  ATM  connections  they  may  have  to  do  so 
across  a  WAN  channel  because  that  is  often  the  initial  link  between  organizations 
deploying  ATM  equipment,  much  like  a  lightweight  heaving  line  is  used  to  pull  a  hawser 
across  or  electrical  fish  tape  is  used  to  pull  cable. 


5.1.3.  Usage>based  Distribution 

The  system  shall  provide  various  mechanisms  in  order  to  distribute  management 
information  and  function  based  on  the  datatype  and  access  usage  of  the  management 
information  concerned.  The  usage  types  shall  include  representatives  of  each  of  the  RFP 
SOW  categories  plus  any  others  judged  necessary  to  demonstrate  the  utility  of  the  Peer  to 
Peer  System  Architecture. 

The  first  usage  type  supported  shall  be  for  monitoring  and  control  that  can  be  bandwidth¬ 
intensive,  either  because  the  component  information  is  volatile  and  a  synchronous  API 
would  be  inefficient  or  because  the  response  is  potentially  very  large.  The  second  usage 
supported  shall  be  for  non-bandwidth  intensive  monitoring  and  control  commands.  The 
third  type  supported  shall  be  for  large  bandwidth  intensive  data  sets.  The  fourth  usage 
supported  shall  be  for  events,  alerts,  traps  or  other  ephemeral  and  asynchronous 
notifications. 

For  example,  the  two  historical  monitoring  functions  described  earlier  impose  distinct 
distribution  requirements.  Monitoring  in  Context  requires  a  synchronous  mode  in  which  a 
current  measurement,  as  well  as  some  statistics  (e.g.  very  recent  history,  median,  5th  and 
95th  percentiles)  that  allow  it  to  be  placed  within  the  appropriate  context,  are  queried  and 
received.  Performance  Analysis  requires  an  asynchronous  mode  in  which  users  subscribe 
to  particular  historical  measurement  data  sets  that  are  potentially  quite  large,  and  receive 
them  periodically  (e.g.  daily). 


5.1.4.  Standard  Distribution  Framework 

While  proposing  a  collection  of  usage-optimized  communication  jargons'  to  distribute 
management  control  and  data  among  peer  systems,  we  do  not  want  to  create  a  set  of  single¬ 
use  spaghetti  strands  drooping  between  systems.  Therefore,  we  consider  a  distribution 
standard  necessary  to  minimize  the  number  and  methods  of  low-level  mechanisms  used  for 
distribution.  These  low-level  standard  capabilities  will  then  be  utilized  in  a  variety  of 
standardized  ways  to  support  usage-optimized  communication  between  the  management 
systems.  Such  a  standard  must  also  support  the  object-oriented  requirement  covered  in 
section  4.2.1  . 
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5.2.  Collateral  Services 


Hooking  together  information  system  distribution  infrastruetures  often  generates 
requirements  based  on  the  integration  proeess  and  also  requires  additional  serviees  not 
direetly  or  immediately  eoneerned  with  mangement  information  transfer  operations 
although  they  often  make  it  possible.  Sueh  eollateral  serviees  requirements  are  addressed 
in  this  seetion  and  inelude  objeet-oriented  development  environments,  distributed  direetory 
(naming)  serviees,  distributed  time  serviees,  seeurity  and  aeeess  eontrol  serviees  with 
network-wide  eoverage,  managed  objeet  management  and  eonfiguration  serviees,  ete. 


5.2.1.  Object-based  datatypes  and  access 

The  system  shall  support  objeet-based  datatypes  and  provide  objeet  methods  so  as  to 
support  aeeess  to  management  information  from  a  wide  variety  of  network  eomponents 
and  management  applieations  without  having  to  explieitly  speeify  eaeh  individual 
interfaee. 

5.2.2.  Integrated  Object  Directories 

The  system  shall  provide  an  integrated  objeet  direetory  for  all  managed  objeets  shared 
among  peer  systems  sueh  that  it  can  be  managed  from  each  system  using  a  standard 
identifier.  Such  a  directory  may  be  manually  populated  and  its  naming  conventions  based 
on  local  agreements. 

5.2.3.  Integrated  Distributed  Time  Services 

The  system  shall  provide  an  integrated  time  service  for  management  operations,  historical 
information  and  logs  such  that  timestamped  information  from  one  source  may  be 
compared  and  sorted  with  timestamped  information  from  another  peer  system.  Such 
integration  may  be  provided  by  a  manually  generated  mapping  between  local  time  zones 
and  local  agreements  about  clock  usage  and  time  providers. 


5.2.4.  Integrated  Security 

The  system  shall  define  and  provide  hooks  for  security  mechanisms  provided  by  Odvssev 
Research  Associates  at  all  necessary  levels.  In  particular  it  shall  provide  hooks  that  allow 
management  systems  to  use  modular  security  mechanisms  that: 

•  authenticate  the  source  and  preferably  the  destination  of  status  updates, 
control  commands,  events,  and  historical  data. 

•  authorize  the  client  application  which  issues  control  commands  or  which 
attempts  to  supply  input  to  a  management  application 

•  ensure  the  integrity  of  such  management  traffic 

•  preserve  management  information  integrity 


Authentication,  Authorization  and  Data  Integrity  mechanisms  shall  be  supplied  by  the 
designated  security  partner,  Odyssey  Research  Associates. 
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Derived  requirements  arising  from  the  need  to  extend  integrated  security  to  WAN 
environments  via  common  security  mechanisms  such  as  firewalls  will  be  considered 
Management  of  Security  of  Management  component  issues  and  again,  hooks  only  will  be 
defined  and  provided. 


5.2.5.  Manageability  of  System  Components 

The  system  itself  shall  have  a  management  interface  such  that  an  authorized  person  can 
review  the  management  system  configuration  information  and  make  necessary  changes. 
The  management  interface  shall  integrate  component  management  system  management 
interfaces  and  BBN  supplied  integration  components,  using,  as  much  as  possible,  the  same 
or  similar  GUI  environments.  Installation  and  other  similar  situations  which  are  prone  to 
bootstrapping  dependency  issues  may  use  methods  other  than  an  integrated  GUI  to 
minimize  the  user  effort  and  learning  curve. 


5.2.6.  Graphic  User  Interface 

The  system  GUI  shall  be  usable  on  the  same  screen  at  the  same  time  as  the  GUI  supplied 
by  the  network  management  platform  (HP  Openview  or  Tivoli  TME).  Where  appropriate, 
the  system  GUI  should  integrate  with  that  of  the  network  management  platform  so  that,  for 
example,  system  functions  can  be  invoked  via  additional  menu  items  or  menus  that  appear 
as  part  of  the  network  management  platform's  GUI 


5.2.7.  Storage 

In  addition  to  distributing  management  information,  each  type  of  usage  has  distinct  storage 
requirements.  For  example,  the  two  historical  monitoring  functions.  Monitoring  in  Context 
and  Performance  Analysis  described  earlier  and  the  Event  Eogs  implied  by  event 
monitoring  also  have  storage  requirements. 

1.  In  the  case  of  monitoring  current  measurement  information  in  context,  the 
information  becomes  obsolete  fairly  rapidly.  Thus,  only  the  most  recently  queried 
information  must  be  cached,  and  only  for  a  limited  period.  To  integrate  two  peer 
systems  means  aligning  cache  purging  procedures  or  providing  a  buffering 
mechanism. 

2.  In  the  case  of  historical  performance  data  or  event  logs,  potentially  large 
amounts  of  data  must  be  stored  for  potentially  extended  periods  of  time.  This  may 
be  done  in  a  centralized  or  a  distributed  database.  Transparency  to  the  end-user  is 
an  important  requirement.  To  integrate  two  peer  systems  means  providing 
consistency  and  update  mechanisms. 


6. 


Executive  Appendices 


6. 1.  Requirements  Matrix 

The  following  matrix  matches  requirements  listed  in  the  Rome  Lab's  RFP 
Statement  of  Work. 


Section 

Requirement 

1.1 

Arch 

Peer  to  Peer  NM  Entity 
Comms 

Arch 

Monitoring,  including 

Status 

Arch 

Control 

Arch 

Fault  Isolation 

Arch 

Multiple  NM  Entities 

Arch 

Info  Flow  Optimization 

Design 

Rome  Testbed  integration 
Demo 

2.1  (also  4.1.1,  4.1.2) 

Study  &  Design 

P2P  communications 

(also  4.1.1) 

S&D 

Applicable  Standards 

(also  4.1.1) 

S&D 

Applicable  Existing 
Technologies 

(also  section  4.1.4) 

Design 

HP  Openview 

(also  section  4.1.4) 

Design 

non-HP  NM  platform 

3.1 

Arch 

End  to  End  Resource 

Mgmt. 

Arch 

Integrated  Security 

Arch 

ATM  as  Network 

Resources 

4.1 

4.1.1 

Sched 

Deliver  Study  Results 

4.1.2 

Sched 

Deliver  Requirements  Doc 
Req  Delivery  Plan 

4.1.3 

Sched 

Deliver  Arch  Doc  Doc 
Delivery  Plan 

4.1.3. 1 

Arch 

Definitions  of  NM  Entities: 
Functionality  & 
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Responsibilities  (e.g. 
eollection,  storage, 
analysis/inference,  display 
from  3.1 

4.1.3.2& 

4.1.3.4 

Areh 

Definition  of  NM  Entity 
Inter-relationships  & 
Mechanisms  (e.g.  equal 
peers,  hierarchical  and  the 
Mgmt.  Info  formats) 

4.1.3.3 

Areh 

Definition  of  System  I/F  to 
Peer  Mgmt.  System 

4.1.4 

Deliver  Implementation 

Plan  (Design  Doc.) 

Design 

Exchange  Mgmt 

Monitoring  &  Control  Info. 

Design 

HP  Openview  Usage 

Design 

non-HP  NM  platform 

Usage 

4.1.5 

Sched 

Implement  Design  sections) 

4.1.5. 1 

Sched 

Deliver  minimum  HP  and 
non-  HP  platform 
configurations  to 

Rome  1  month  after 
approval 

4.1.5.2 

Sched 

Deliver  Phased  Releases  of 
Impl  Starting  with  4. 1.5.1 

4.1.6 

Sched 

Two  Proof  of  Concept 

Demos 

4.1.6.1 

Sched  &  Impl 

Demo  Exchange  of 
Monitoring  Info,  including 
Status 

4.1.6.2 

Sched  &  Impl 

Demo  Exchange  of 
Monitoring  Info,  including 
Status  and 

Control  Info 

Sched 

Deliver  Source, 

Executables,  Eibraries  and 
Tools  (all  properly  licensed) 
using  3  or  fewer  BBN 
personnel  in  5  days  or  less. 

4.1.7 

Sched 

Reports 
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4.1.7.1 

Sehed 

Monthly  Status  Reports 

4.1.7.2 

Sehed 

Funding  Status  Reports  as 
required 

4.1.7.3 

Sehed 

Researeh  Results  and 
Evaluations  as  Seientifie  & 
Teohnieal  Reports,  and 

Teeh.  Info  Reports,  as 
required  plus  a  final  S  &  T 

4.1.7.4 

Sehed 

Teehnieal  Status 

Presentations 

4.1.7.5 

Sehed 

Attend  Teehnieal 

Interehange  Meetings 

6.2.  On-line  References 

The  following  are  the  on-line  referenees  elsewhere  in  this  doeument;  they  will  beeome 
stale  over  time  and  should  be  treated  as  sueh  by  January,  1998.  In  some  eases,  loeally- 
stored  snapshots  have  been  made  to  minimize  loss  of  the  referenee.  Paper  eopies  of 
snapshots  of  non-projeet  doeuments  will  be  provided  at  the  end  of  the  projeet . 

P2P  Study/Survey 

httr)://morDheus.bbn.eom/r)2r)/resDocs/nm.html  . 

P2P  System  Arehiteeture 

httD://morDheus.bbn.eom/D2D/resDoes/svsareh.html . 

XBind 

httD://www.etr.eolumbia.edu/eomet/xbind/xbmd.html . 

SNMP  V2  [IETF] 

http://www.ietf  org/ids.bv.wg/snmr)v2.html . 

SNMP  V2  [BBN] 

http://morpheus.bbn.eom/p2p/resDoes/snmpv2.html . 

IETF  MIBs  [IETF] 

•  RFC  1902  whieh  defines  the  SMI,  the  meehanisms  used  for  deseribing  and 
naming  objeets  for  the  purpose  of  management. 

•  STD  17,  RFC  1213  defines  MIB-II,  the  eore  set  of  managed  objeets  for  the 
Internet  suite  of  protoeols. 
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•  SNMPv2  Working  Group,  Case,  J.,  McCloghrie,  K.,  Rose,  M.,  and  S. 
Waldbusser,  "Strueture  of  Management  Information  for  version  2  of  the  Simple 
Network  Management  Protoeol  (SNMPv2)",  RFC  1902,  January  1996. 

•  M.T.  Rose  (editor).  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  internets,  Internet  Working  Group  Request  for  Comments  1213. 
Network  Information  Center,  SRI  International,  Menlo  Park,  California,  (March, 
1991). 


Odyssey  Research  Associate 

httD://www. oracorD.com/  . 


12 


Section  1  -  Current  Network 
Management  Technologies 


7.  Overview 

This  survey  of  network  management  tools  is  submitted  in  fulfillment  of  requirement  4.1.1 
and  CDRL  A004  from  the  Statement  of  Work  for  the  Peer-to-Peer  Information  System 
Management  Contract  #F30602-96C-0049. 

There  are  two  primary  goals  for  this  survey: 

First,  to  provide  the  sponsor  with  a  critical  overview  of  the  systems,  standards,  and 
technologies  pertinent  to  the  development  of  a  generic  peer-to-peer  communication 
architecture  for  network  management  systems  (NMS). 

Second,  to  select  an  appropriate  network  management  tool  to  use  in  the  prototype  peer-to- 
peer  network  management  system  to  be  developed  in  the  next  phase  of  the  project.  In  the 
Statement  of  Work,  the  sponsor  identified  HP  OpenView  as  one  of  two  systems  to  use  in 
the  prototype;  the  choice  of  the  other  system  is  to  be  recommended  by  BBN,  as  a  result  of 
this  survey. 


This  survey  was  conducted  in  order  to  meet  several  objectives  for  the  critical  overview  of 
the  current  state  of  network  management  systems: 

1 .  To  determine  what  software  products  and  technology  are  widely  available 
including  determining  which  products  are  leaders  in  the  market  place. 

2.  To  determine  which  companies  and  products  are  providing  leading  edge  or 
innovative  solutions. 

3.  To  determine  what  organizations  are  actively  involved  in  developing  standards. 

4.  To  identify  projects  at  universities  or  other  organizations  involving  leading  edge 
research  in  the  area  of  network  management. 

The  survey  addresses  each  of  these  areas  and  concludes  with  a  recommendation  for  the 
network  management  system  to  be  used  in  the  prototype  peer-to-peer  communications 
system  to  be  designed  and  implemented  in  the  next  phase  of  this  project. 

As  network  management  technology  and  tools  are  rapidly  evolving,  this  survey  has  been 
delivered  in  two  forms:  the  standard,  hard  copy  report  and  a  document  on  the  world  wide 
web.  In  the  latter  form,  the  survey  includes  references  to  relevant  web  sites  from  industry, 
education,  and  research  and  standards  organizations.  In  that  form,  the  survey  is  a  "living" 
document,  providing  up-to-date  information  more  current  than  the  publication  date  of  the 
hard  copy  document.  As  the  location  and  availability  of  web  documents  may  change  over 
time,  all  referenced  web  pages  have  been  copied  to  a  server  at  BBN  where  they  will  be 
maintained  for  the  life  of  the  contract.  Each  of  these  web  pages  contains  the  location  of  the 
original  web  page. 


13 


7. 1.  Network  Management  Platform  for  Prototype  Peer-to-Peer  System 

We  recommend  Tivoli  as  the  Network  Management  Platform  to  integrate  with  HP 
OpenView  in  the  Prototype  Peer-to-Peer  System  to  be  developed  in  the  next  phase  of  this 
project. 

7.2.  Criteria 

The  criteria  for  selection  of  a  second  network  management  system  for  the  prototype  phase 
of  the  project  are  both  technical  and  non-technical. 

The  non-technical  criteria  include: 

•  Availability  —  Can  the  system  be  obtained  by  other  organizations  that  might  be 
interested  in  making  use  of,  or  pursuing  further  research  on,  our  work? 

•  Support  —  Is  the  system  currently  supported?  Is  the  vendor  committed  to  support 
and  improve  the  product  for  the  forseeable  future? 

•  Manageability  —  Is  the  vendor  available  for  technical  support?  (On  this  point, 
vendors  were  judged  by  how  well  they  responded  to  requests  for  information  for 
this  survey.) 

•  Environment  —  Can  the  system  be  run  on  a  Sun  or  HP  workstation? 

•  Performance  —  Will  the  system  perform  reasonably  well,  not  only  in  a  prototype 
environment,  but  also  in  a  real-world  network? 

We  first  applied  the  above  non-technical  criteria,  primarily  through  literature  searches  and 
searches  of  online  information,  to  choose  a  small  number  of  systems  from  the  many 
network  management  systems  available. 

In  applying  the  non-technical  criteria,  we  decided  to  restrict  further  consideration  to  the 
leading  COTS  vendors.  These  vendors  meet  the  criteria  of  availability  and  support. 

Further,  these  vendors  have  demonstrated  that  their  products  can  perform  in  real-world 
environments.  All  the  vendors  considered  deal  with  performance  limitations  by 
subdividing  the  overloaded  domain  and  installing  additional  managers.  Managing  such  a 
configuration  may  be  difficult  in  very  large  networks,  but  this  strategy  is  very  common. 

Finally,  and  perhaps  most  importantly,  integration  of  a  widely  available  COTS  product  in  a 
peer-to-peer  management  scheme  will  validate  this  methodology  in  a  way  that  freeware  or 
customized  software  could  not. 

After  narrowing  our  choices  to  a  few  leading  COTS  vendors,  we  arranged  for  presentations 
by  vendors  and  studied  the  product  technical  manuals. 

The  primary  technical  criteria  for  selection  of  a  network  management  platform  for  the 
prototype  phase  of  the  project  are: 

•  Ease  of,  or  support  for,  CORBA  integration,  including: 

•  CORBA  wrappers  for  non-CORBA,  proprietary  object  APIs 

•  ORB  interoperability  for  CORBA  compliant  object  APIs 

•  IDL  back-end  support  for  CORBA  compliant  object  APIs  for  C++ 

•  Support  for  the  ‘jargons’  (events,  status,  control,  trend)  outlined  in  the  proposal 
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7.3.  CORBA  Integration 

One  of  the  purposes  of  this  projet  is  to  demonstrate  how  the  old  "request/response" 
approaeh  to  distributing  management  information  is  insuffieient  to  eover  the  full  range  of 
management  aetivities.  We  will  use  CORBA  to  ereate  "request/response"  objeets  (for 
eontrol  information),  eomposite  "stream"  objeets  (for  status  and  other  monitoring),  and 
other  jargon  objeets  that  are  deemed  neeessary.  These  different  types  of  objeets  will  be 
able  to  eoexist  in  a  CORBA  framework,  as  will  be  demonstrated  in  the  prototype  phase  of 
the  projeet. 

Any  seeondary  platform,  in  addition  to  the  HP  OpenView  platform  required  by  the 
sponsor,  should  provide  a  CORBA  V2.0  eompliant  developer's  environment  for  on-site  or 
third-party  applieations.  CORBA  will  be  used  as  the  basis  for  the  manager-to-manager 
integration.  Although  a  CORBA  interfaee  is  not  strietly  neeessary,  additional  work  would 
be  required  to  "CORBAsize"  objeets  to  be  imported/exported  and  integrated  aeross 
platforms.  As  HP  OpenView  does  not  offer  a  CORBA  API,  the  interfaee  to  this  platform 
will  inelude  CORBA  wrappers  for  shared  objeets. 

Assuming  a  CORBA  requirement,  the  leading  COTS  produets  are  ranked  as  follows,  based 
on  their  applieation  interfaees: 

•  Tivoli  TME 10  (native  CORBA) 

•  Cabletron  Speetrum  (proprietary,  open,  obieet-oriented  APIs,  with  promised  future 
support  for  CORBA) 

•  Computer  Assoeiates  Unieenter  (proprietary,  objeet-oriented  APIs,  but  no  CORBA 
support) 

•  Sun  Solstiee  (CMIS  API;  plans  to  support  Java  API,  but  no  immediate  plans  to 
support  CORBA) 

•  Bull  OpenMaster  (CMIP  APIs) 

7.4.  Support  for  Jargons 

We  studied  the  Applieation  Programming  Interfaees  of  the  various  tools  in  an  attempt  to 
deeide  how  well  they  would  support  the  jargon  approaeh.  Questions  sueh  as  "Does  the 
NMS  provide  Event  proeessing?"  "How  does  the  NMS  allow  applieation  developers  to 
define  objeets  so  that  we  ean  translate  GETs  and  SETs?”  “Do  we  have  to  map  GET-RESPs 
into  Events  on  the  seeond  system  beeause  the  seeond  system  didn't  issue  a  GET-REQ?" 
beeame  seleetion  eriteria  when  we  attempted  to  see  how  well  our  initial  system 
arehiteeture  would  be  supported.  In  this  preliminary  arehiteeture,  managers  will  exehange 
a  subset  of  the  jargons  as  follows: 

Events  will  be  be  exehanged  by  mapping  an  EVENT  message  from  NMS  I's  managed 
objeet  through  a  CORBA  Event  Stream  into  an  EVENT  message  in  NMS  2. 

Status  will  be  exehanged  by  mapping  a  sequenee  of  GET-RESPs,  whieh  are  replies  to 
NMS  I's  polls,  into  a  MIST  stream  objeet,  and  then  mapping  these  into  a  sequenee  of 
GET-RESPs  to  NMS  2's  events/alarms/alerts. 

Control  will  be  supported  by  forwarding,  via  a  proxy  objeet,  the  SET-REQ  from  NMS  1  to 
NMS  2,  whieh  will  then  send  it  as  the  "real"  objeet. 
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The  exchange  of  trend  data  will  be  supported  by  forwarding  a  GetIFFLog  from  NMS  1 
through  a  CORBA  transport  object  to  NMS2,  then  forwarding  the  RespIFFLog  back 
through  a  (potentially  different)  CORBA  transport  object. 

CORBA  Transport  objects  are  different  than  CORBA  Management  objects  in  that  a 
Management  object's  IDL  defines  a  MIB-based  Request/Response  interface,  and  a 
Transport  object's  IDL  typically  defines  stream  or  other  transport-based  characteristics. 
Transport  objects  distribute  a  particular  type  of  management  information  (the  MIB's  event 
in  the  case  of  the  Event  Stream,  the  MIB's  status  attribute  in  the  case  of  the  MIST,  the  IFF 
file  in  the  case  of  the  Trend  transporter).  Transport  objects  will  enable  the  prototype 
system  to  work  around  the  Request/Response  communication  paradigm  that  CORBA 
normally  uses,  while  staying  within  the  CORBA  framework  for  integration  purposes. 

In  summary,  the  network  management  platform  chosen  must  allow 

•  the  definition  of  MIB-based  gateway  objects  in  the  network  management  platform 
and  matching  CORBA  components,  and 

•  the  definition  of  transport-based  application  objects  that  convey  Events,  Status, 
Control  and  Trend  information,  between  the  source  NMS  MIB  object  (or 
application  in  the  case  of  the  Trend  Eogs),  and  the  destination  application. 
Destination  applications  include  Logger  for  Events,  Monitor/Display  for  Status  and 
other  monitoring  items,  and  Trend  Analysis/Eogger  for  Trend  Eogs. 

Several  platforms  support  definition  of  MIB-based  objects  in  their  native  mode.  Only  one 
platform,  Tivoli,  is  CORBA-native.  Definition  of  a  CORBA  half-gateway  for  non- 
CORBA-native  platforms  is  platform-specific.  This  support  will  have  to  provided  for  HP 
OpenView,  which  is  not  CORBA-native.  The  OpenView  integration  will  prove  the  concept 
for  MIB-based,  non-CORBA  objects. 

7.5.  Notes  on  Initial  Design  Approach 

The  Tivoli  ORB  supports  both  WAN  directory  services  and  WAN  object 
reference/invocation. 

Tivoli's  ORB  is  only  CORBA  1.2  compliant  because  they  feel  that  their  security  interface 
cannot  co-exist  with  the  CORBA  V2.0  Internet  Inter-ORB  Protocol  (HOP).  Tivoli  is  also 
awaiting  standardization  of  the  Common  Eacilities  Transaction  Service  as  they  feel  that  it 
is  critical  for  network  management.  Einally,  they  do  not  support  Context  arguments  on 
CORBA  interface  calls,  although  this  is  not  essential  for  the  peer-to-peer  system. 

There  are  two  design  approaches  for  integrating  the  Tivoli  system; 

•  Wrap  Tivoli  objects,  much  like  any  other  non-CORBA  objects. 

•  Attempt  to  implement  the  jargons  (e.g.  MIST)  in  ORB  terms. 

The  first  choice  implies  that  Tivoli  is  not  much  better  than  other  choices  considered  in  the 
survey.  Even  though  it  is  CORBA-compliant,  a  CORBA  vL2/CORBA  v2.0  wrapper  or 
gateway  will  have  to  be  provided.  On  the  positive  side,  a  CORBA  vL2/CORBA  v2.0 
gateway  is  probably  the  easiest  of  the  wrapper-based  jargons  to  design  and  implement. 

The  second  approach  means  the  the  MIST  must  be  ported  to  Tivoli  and  the  other  jargons 
must  be  developed.  Tivoli  does  provide  a  fairly  standard  IDE  compiler,  but  there  is  no 
mention  of  persistence  or  replication  in  their  documentation.  The  directory  service  and 
access  are  both  purportedly  WAN-based. 
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We  propose  to  use  the  seeond  approaeh  as  our  initial  design;  if  this  approaeh  proves 
infeasible,  the  results  ean  be  ineorporated  into  the  first  approaeh.  This  approaeh  will  give 
us  (and  Tivoli)  a  elear  idea  of  what  is  required  of  a  CORBA-eompliant  NMS  by  third  party 
developers  and  will  give  the  elient  an  indication  of  what  CORBA/CORBA  interactions 
entail.  Eventually,  we  hope  that  a  Tivoli  CORBA/CORBA  wrapper  would  define  the  API 
that  would  run  on  top  of  HOP  for  Tivoli  CORBA  V2. 

8.  Industry  Leaders  and  Products 

There  are  a  small  number  of  companies  that  account  for  most  of  the  market  share  in 
network  management  tools.  The  leading  contenders  and  their  product  lines  are: 

•  IBM/Tivoli/TMEIO 

•  HP/OpenView 

•  Bull/ISM  OpenMaster 

•  Cabletron/Spectrum 

•  CA/Unicenter 

•  Sun/Solstice  Enterprise  Manager 

Each  of  the  following  sections  includes  a  reference  to  the  company's  home  page  and  a 
reference  to  the  product  home  page. 

8.1.  Tivoli  TME10 

(http://www.tivoli.com) 

(http://www.tivoli.com/tivevery/prodhm.html) 

Tivoli  Systems  was  acquired  by  IBM  in  early  1996.  The  IBM  NetView  product  has  been 
replaced  by  the  Tivoli  suite  of  products. 

8.1.1.  Environment 

The  currently  supported  platforms  include: 

•  Solaris  2.3  or  2.4 

•  HP/UX  9.0  through  9.05 

8.1.2.  Framework  Services 

Tivoli  Systems,  a  subsidiary  of  IBM,  offers  a  CORBA  1.2  compliant  Advanced 
Developer's  Environment.  The  ORB  was  developed  by  Tivoli  and  is  known  as  the  Tivoli 
Management  Eramework  (TME).  APIs  are  either  developed  by  linking  to  C  runtime 
libraries  or  by  linking  to  client  stubs  generated  by  compiling  standard  CORBA  IDE. 
Currently,  only  BOA-style  stubs  are  offered. 

Tivoli  has  been  active  in  the  OMG,  but  they  claim  to  be  focusing  on  system  management 
standards,  although  their  submissions  can  be  considered  generic  approaches  to  policy 
definition  and  propagation,  object  instance  repository/directory  services,  object  instance 
grouping  (known  as  the  Collection  Service),  and  operation  scheduling. 

Tivoli  handles  WAN  and  scalability  issues  by  employing  multiple  Tivoli  Management 
Region  (TMR)  servers  interconnected  with  a  private  protocol.  The  TMR  holds  the  Tivoli 
Naming  Registry  (TNR),  an  object  instance  repository,  and  a  directory  service. 
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Tivoli  provides  extensions  to  IDL  (TEIDL)  that  support: 

•  Implementation  inheritanee  from  multiple  proeesses  aeross  the  network. 

•  Instantiable  elass,  abstraet  elass,  meta-elass,  and  mix-in  elass  speeifieation. 

•  A  distributed  Seeurity  model  with  the  ability  to  set  per  method/per  objeet  ACLs 
using  both  simple  TMF  and  DES  algorithms. 

•  A  rieh  set  of  method  aetivation  polieies  ineluding  shared/unshared  server,  external, 
and  multi-threaded. 

•  Initialization  and  installation  features  to  automate  applieation  installation  into  a 
live,  running  system. 

•  A  eompiler  option  for  striet  OMB/CORBA  eomplianee 

Tivoli  also  provides  a  number  of  eollateral  serviees  (both  Common  Objeet  Serviees  and 
Common  Faeilities  Arehiteeture  serviees),  partieularly  a  Transaetion  serviee,  in  addition  to 
the  Naming  and  Seeurity  serviees  mentioned  above. 

8.1.3.  Event  Services 

Tivoli  provides  the  Tivoli  Event  Console  (TEC),  whieh  is  a  rule-based  eorrelation  and 
filter  engine  with  a  Sybase  baek-end  that  eommunieates  with  Event  Adapters  (both  Tivoli 
supplied  and  eustom)  and  the  TMR  (whieh  also  provides  simple  thresholding/bloeking). 

Up  to  six  events  per  seeond  ean  be  handled. 

8.1.4.  GUI 

Tivoli's  Desktop  Services  offers  XI 1R5,  Motif  1.2,  and  Windows  3.1 -compatible 
presentation  API,  but  it  assumes  a  request/response  model  (although  callbacks  are 
supported).  The  main  components  are: 

•  Dialog  Specification  Eanguage/Compiler 

•  TME  desktop  display  manager  and  command/callback  engine 

•  Desktop  services  library 

•  Gadget  library 

8.1.5.  Security 

Kerberosized  RPC  and  an  optional  data  encryption  service. 

8.1.6.  Contacts 

This  review  is  based  on  a  presentation  and  demo  given  by  Tivoli  (Eyssa  Robinson)  at  BBN 
Planet  on  November  1 ,  on  subsequent  phone  conversations  with  Eyssa  Robinson,  on  the 
tutorial  manual  Introduction  to  Tivoli/ ADE  V3.0,  and  on  the  rest  of  the  ADE 
Documentation  set  as  specified. 

•  Contact  information  for  Eyssa  Robinson,  systems  engineer,  is  as  follows:  408-369- 
3930,  408-369-3939  (fax),  lyssa.robinson@tivoli.com,  in  the  Campbell,  CA  office. 

8.1.7.  Tivoli  References 

The  following  white  paper  was  provided  by  Tivoli. 


18 


8.1. 7.1.  Tivoli  Management  Environment  and  CORBA 

The  purpose  of  this  paper  is  to  diseuss  Tivoli's  perspeetive  with  regard  to  the  OMG 
CORBA  speeification.  Tivoli  has  been  closely  involved  in  the  evolution  of  the  OMG 
specifications  within  the  OMG.  Our  activities  include  direct  contributions  on  the 
evolution  of  the  security  specification  that  is  being  defined  for  use  within  a  CORBA 
environment  (the  importance  of  this  will  be  made  clear  in  the  sections  that  follow), 
the  evolution  of  the  CORBA  specification  itself,  and  the  acceptance  within  the  OMG 
of  the  Common  Management  Facilities  specification  (derived  from  the  work  of  the 
X/Open  Systems  Management  Technical  Working  Group  to  define  a  set  of 
management  services  based  on  the  CORBA  specification).  Based  both  on  our  direct 
involvement  in  a  number  of  the  OMG  working  groups  as  well  as  our  commitment  to 
base  our  product  on  relevant  OMG  specifications,  Tivoli  has  long  been  a  supporter 
of  the  goals  of  the  OMG,  and  much  of  its  current  core  technology  is  based  on  the 
work  of  this  group. 

Tivoli  Management  Environment  and  CORBA  1.2 

With  the  2.0  release  of  the  Tivoli  Management  Environment,  Tivoli  became  the  first 
Distributed  Systems  Management  software  provider  to  deliver  a  solution  which  is 
compliant  with  the  OMG  CORBA  1 .2  specification.  The  specification  has  been 
proposed  and  accepted  as  a  standard  for  all  common  ORB  systems.  The 
implementation  of  this  standard  as  part  of  the  Tivoli  Management  Eramework  has 
enabled  customers  to  utilize  TME  to  manage  very  large  scale  heterogeneous  computing 
environments  with  unprecedented  ease. 

CORBA  1 .2  only  specifies  the  architecture  of  the  ORB  model.  That  is,  it  specifies  the 
provision  of  the  ORB  interfaces  but  it  does  not  specify  the  ORB  implementation.  The 
ORB  could  for  example,  be  implemented  as  part  of  the  operating  system  or  as  a  stand 
alone  process.  The  TME  framework  services  provide  a  server-based  ORB,  which 
means  that  the  TME  ORB  is  a  continually  running  program,  separate  from  the 
operating  system.  The  TME  ORB  communicates  with  both  the  server  and  the  client 
through  separate  stubs  and  skeletons  via  an  inter-process  communication  facility.  A 
secure  remote  procedure  call  (RPC)  use  to  invoke  operations  on  remote  objects 
provides  both  principal  authentication  and  authorization.  CORBA  1 .2  also  does  not 
specify  an  interoperability  protocol,  thus  there  is  no  specification  that  an  ORB 
developer  can  implement  to  with  any  confidence  that  one  implementation  can  inter¬ 
operate  with  another. 

The  Tivoli  framework  services  support  all  the  major  CORBA  1.2  components 
including  an  Object  Request  Broker,  a  Basic  Object  Adapter,  an  extended  IDE 
compiler  with  both  ANSI  C  and  bourne  shell  language  bindings,  an  interface  repository 
and  the  interfaces  required  for  a  Dynamic  Invocation  Interface  (DII).  The  TME 
framework  services  do  not,  however,  currently  support  optional  context  objects.  The 
CORBA  1.2  specification  of  context  objects  is  obscure;  and  there  is  significant 
disagreement  as  to  its  use  and  benefit  in  the  standard. 

In  addition  to  these  components  the  Tivoli  Management  Eramework  supports 
additional  services  required  for  secure  and  scaleable  distributed  systems  management 
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solutions.  These  serviees  provide  support  for  seeurity  and  transaetions  at  the  ORB 
layer.  For  example,  eaeh  ORB  is  fully  authentieated  from  a  eentral  seeurity  server,  so 
that  an  ORB  running  on  one  Tivoli  managed  node  will  only  aeeept  ORB  requests  from 
some  other  ORB  in  the  Tivoli  Managed  Region  (within  the  seeurity  domain  of  the 
same  eentral  seeurity  server).  ORB  eommunieation  ean  optionally  be  enerypted  to 
preserve  data  integrity  and  privaey.  Finally,  ORB  requests  oeeur  within  the  seeurity 
eontext  of  the  administrator  making  the  management  request,  and  this  information  is 
used  to  verify  that  an  administrator  has  the  neeessary  seeurity  eredentials  to  perform 
the  operation  (i.e.  invoke  the  requested  method  on  the  speeified  objeet)  in  the  TMR. 

Tivoli  also  ineludes  support  for  transaetions,  whieh  allow  method  invoeations  to  oeeur 
within  a  top-level  or  nested  transaetion  eontext.  Within  this  eontext,  any  modifieations 
to  any  objeet  attribute  data  is  staged  for  a  later  eommit  or  abort  operation.  This 
meehanism  guarantees  that  persistent  objeet  attribute  data  from  objeets  that  reside  on 
more  than  one  ORB  ean  be  maintained  in  a  eonsistent  state.  Without  this  capability  the 
recovery  actions  that  must  be  provided  when  distributed  operations  are  not  able  to 
complete  successfully  in  the  distributed  environment  would  be  extremely  cumbersome, 
expensive,  and  error-prone. 

Whafs  new  in  CORBA  2.0? 

Unlike  CORBA  1.2,  CORBA  2.0  is  actually  a  family  of  specifications,  and  support  a 
number  of  different  capabilities.  The  set  of  specifications  include  core  capabilities, 
support  for  interoperability,  support  for  a  C++  binding,  and  support  for  enhanced 
portability. 

The  most  interesting  extension  to  the  core  capabilities  offered  by  CORBA  2.0  is  a 
Dynamic  Server  Interface.  Of  course,  the  most  visible  CORBA  2.0  specification  is  the 
support  for  interoperability,  defined  by  the  Internet  Interoperability  Protocol  (HOP), 
which  defines  the  wire-level  protocol  that  allows  an  IlOP-compliant  ORB  provided  by 
one  vendor  to  inter-operate  with  a  second  IlOP-compliant  ORB  provided  by  another. 
The  C++  binding  defined  by  CORBA  2.0  allows  a  CORBA  2.0-comphant  IDL 
compiler  to  emit  interface  definitions  using  C++  instead  of  C,  so  that  the  C++  class 
library  support  built  into  most  C++  development  environments  can  be  used  on  IDL- 
defined  interface  definitions.  Finally,  the  enhanced  portability  services  provides 
additional  object  life  cycl  e  services  that  increase  the  chances  that  interfaces  defined  by 
one  IDL  compiler  can  be  ported  to  another. 

Of  these,  perhaps  the  only  CORBA  2.0  specification  that's  particularly  useful  to  DSM 
solutions  would  be  the  support  for  interoperability.  The  remainder  of  the  CORBA  2.0 
services  are  primarily  of  interest  to  general-purpose  ORB  vendors,  because  they 
increase  the  likelihood  that  an  application  developed  on  one  ORB  from  one  vendor 
would  easily  port  to  a  second  ORB  from  another  vendor.  Since  this  is  not  the 
environment  that  Tivoli's  ORB  is  used  in,  the  particular  value  of  CORBA  2.0  to 
Tivoli's  customers  is  more  as  an  indicator  of  Tivoli's  commitment  to  CORBA-based 
standards  initiatives  and  to  Tivoli's  commitment  to  continue  to  invest  and  support  its 
ORB-based  technology. 

Tivoli's  position  with  regard  to  CORBA  2.0 
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As  noted  above,  two  base  services  essential  for  DSM  is  support  for  a  fully  secure 
environment  and  the  error  recovery  inherent  in  a  distributed  transaction  environment. 
CORBA  2.0  addresses  neither  of  these  two  key  services,  and  represents  the  biggest 
stumbling  block  for  Tivoli  moving  to  CORBA  2.0.  To  fully  explain  Tivoli's  position 
with  regard  to  CORBA  2.0,  it's  important  to  address  both  sets  of  issues  above  (the 
specifics  of  CORBA  2.0  support  _AND_  Tivoli's  long-term  commitment  to  CORBA). 
Let's  address  the  second  issue  first. 

When  Tivoli  first  set  out  to  develop  a  framework,  one  of  the  key  requirements  was  an 
object-based  technology  that  could  cleanly  and  portably  run  across  hardware  and 
operating  systems  from  multiple  vendors.  The  only  technology  which  meets  these 
requirements  is  CORBA.  Therefore,  Tivoli  adopted  the  then-current  version  of 
CORBA  (1.2)  as  its  base  standard  both  for  its  ORB  implementation  and  as  the 
programming  environment  for  both  its  management  services  and  its  management 
applications.  Of  course,  that  version  of  the  CORBA  specification  did  not  include 
support  for  security,  transactions,  implementation,  etc.,  and  Tivoli's  implementation  of 
CORBA  1 .2  is  an  "extended  implementation"  in  that  it  includes  support  for  these 
services. 

When  CORBA  2.0  was  released,  Tivoli  evaluated  the  various  additional  services 
included  in  CORBA  2.0  and  determined  that  the  core,  C++,  and  enhanced  portability 
services  of  CORBA  2.0  did  not  add  sufficient  additional  benefit  to  Tivoli  to  merit  the 
development  expense  of  evolving  to  the  new  version  of  the  specification.  The  one 
feature  that  did,  on  the  surface,  merit  that  expense  was  support  for  interoperability 
through  the  HOP.  However,  there  was  a  catch.  As  noted  earlier,  Tivoli  had  to  extend 
the  CORBA  1 .2  specification  to  include  support  for  security  and  transactions,  based  on 
our  strongly-held  belief  that  these  services  were  essential  to  a  robust,  enterprise-wide, 
scaleable  systems  management  framework.  While  CORBA  2.0  provides  a  number  of 
useful  additions  to  CORBA  1 .2,  it  does  not  yet  include  support  for  these  two  essential 
services.  If  Tivoli  were  to  embrace  the  CORBA  2.0  specification,  Tivoli  would  (again) 
have  to  extend  the  implementation  of  its  ORB  to  provide  support  for  these  services. 
Based  on  this  observation,  the  benefit  of  interORB  interoperability  would  be  lost  once 
the  additional  support  for  security  and  transactions  was  added  back  in  (since  no  other 
IlOP-compliant  ORB  would  understand  how  to  talk  to  Tivoli's  ORB  and  visa-versa). 

So,  from  Tivoli's  perspective,  the  CORBA  2.0  specification  is  incomplete,  doesn't 
provide  sufficient  benefit  for  the  effort  involved,  and  doesn't  justify  evolving  its  entire 
customer  base  over  to  a  new  version  of  our  ORB  for  such  minimal  benefit. 

What  about  interoperability? 

In  many  cases  customers  express  interest  in  being  able  to  inter-operate  between  Tivoli's 
ORB  and  an  ORB  from  some  other  vendor.  This  is  often  the  driving  force  behind 
questions  regarding  our  plans  with  CORBA  2.0.  As  should  be  clear  from  statements 
above,  even  if  Tivoli  were  to  make  TME  CORBA  2.0-compliant,  our  security 
extensions  would  prevent  another,  external  ORB  from  communicating  with  a  TME 
ORB  and  visa-versa.  In  effect,  the  Tivoli  security  services  perform  the  same  function 
that  a  firewall  performs  in  an  network  connected  to  the  Internet. 
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While  IP,  in  general,  provides  for  eross-network  interoperability,  the  firewall  prevents 
unauthorized  aeeess  to  nodes  within  the  firewall  for  those  users  that  laek  the 
appropriate  permissions.  Therefore,  CORBA  2.0  eomplianee  would  not  address  the  real 
eustomer  requirement:  to  be  able  to  have  applieations  developed  using  one  ORB 
teehnology  aeeess  objeets  within  the  TME  and  visa-versa.  For  those  eustomers  with 
this  requirement,  there  is  another  approaeh. 

Our  reeommendation  for  sueh  interoperability  is  to  define  gateway  objeets  that  provide 
interfaee  definitions  aeeessible  from  within  one  ORB  environment  that  ean  then  make 
method  ealls  to  analogous  objeets  in  the  other.  In  this  way,  the  gateway  objeet  ean  be 
given  the  neeessary  seeurity  eontext  to  properly  invoke  the  neeessary  operations  within 
the  TME  environment  and  send  the  results  baek. 

Eikewise,  a  similar  gateway  objeet  ean  be  defined  that  intereepts  method  ealls  to  TME 
objeets  in  the  TME  environment  and  then  makes  the  analogous  methods  ealls  to  objeets 
in  the  non-TME  ORB  environment  and  forwards  the  results  of  these  ealls  baek  to  the 
ealler  within  the  TME  environment.  This  is  an  approaeh  that  maintains  the  neeessary 
seeurity  and  transaetion  eontext  within  TME  yet  provides  whatever  level  of 
interoperability  the  applieation  needs.  A  number  of  eustomers  with  this  requirement 
have  used  this  approaeh  with  satisfaetory  results. 

Whaf  s  the  next  step? 

The  OMG  is  eurrently  working  on  both  a  seeurity  speeifieation  and  a  transaetion 
serviee  for  inelusion  in  a  future  version  of  the  CORBA  speeifieation.  When  that  future 
version  of  the  CORBA  speeifieation  is  available,  Tivoli  is  eommitted  to  evolving  to 
that  (more  eomplete)  version  of  CORBA.  Tivoli  has  been  and  will  eontinue  to  be  a 
driving  foree  and  signifieant  supporter  of  the  work  on  the  CORBA  speeifieation.  Today 
Tivoli  is  delivering  distributed  systems  management  solutions  that  are  based  on  a 
subset  of  the  CORBA  2.0  speeifieation  and  in  the  eases  detailed  above  we  have  gone 
beyond  this  speeifieation  with  our  extensions  for  seeurity  and  transaetions  serviees.  It 
is  a  eombination  the  these  serviees  and  the  CORBA  base  speeifieation  whieh  have 
proven  to  be  instrumental  in  sueeessfully  solving  the  problems  of  distributed  systems 
management. 

8. 1.7.2.  Interview  with  Tivoli  CEO,  Frank  Moss 

In  an  interview  in  Computer  Reseller  News,  July  8,  1996,  n69I  pI28(I),  Frank  Moss, 

Tivoli  CEO,  had  the  following  eomment  about  the  future  of  network-eomputing 
management: 

"But  we  believe  that  the  ultimate  direetion  of  network-eomputing  management  is 
applieation  management,  whereby  eustomers  manage  their  entire  environments  from 
the  point  of  view  of  the  applieations  they  are  trying  to  deploy.  After  all,  if  s  the 
applieations  that  are  really  the  heart  of  their  business.  We've  ereated  an  interfaee 
speeifieation  ealled  AMS-for  applieations  management  speeifieations-whieh  eonneets 
TME  with  applieations  and  applieation-development  environments." 

This  is  a  trend  that  has  been  observed  in  looking  at  several  network  management  tools, 
namely  an  emerging  emphasis  on  applieation-to-applieation  level  management  in  an  effort 
to  address  the  question:  "how  are  my  applieations  running?"  In  order  to  answer  this 
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question,  management  tools  must  merge  information  over  a  wide  range  of  devices 
operating  at  different  points  in  the  network/system  hierarchy,  addressing  everything  from 
"are  my  transmission  lines  operational?"  or  "are  my  routers  congested?"  to  "does  my 
system  have  enough  storage?"  or  "is  my  system  CPU-bound?".  This  spans  some  very 
complex  management  issues  (network  management  alone  has  certainly  not  been 
"resolved")  and  it  is  unclear  whether  companies  can  deliver  on  their  goals  in  this  area. 

8. 1.7. 3.  Interview  with  Tivoli  CEO,  Frank  Moss 

In  an  interview  published  in  InfoWorld,  March  25,  1996  vl8  nl3  p45(2),  Frank  Moss  was 
questioned  about  whether  Tivoli  would  maintain  its  independence  after  being  acquired  by 
IBM.  Moss  pledged  that  Tivoli  would  remain  "cross  platform  and  agnostic  about  operating 
systems"  and  that  Tivoli  would  continue  "to  work  with  IBM's  databases  and  platforms 
exactly  the  same  way  we  work  with  other  vendors  now"  (i.e.  before  the  merger). 

Given  that  the  merger  has  been  relatively  recent  (February,  96),  it  remains  to  be  seen 
whether  Tivoli  continues  to  maintain  its  platform  independence. 

8.2.  HP  Open  View 

(http://www.hp.com) 

(http://www.hp.com/nsmd/ov/main.html) 

HP  OpenView  is  the  leader  in  market  share  in  network  management  tools.  As  specified  in 
the  Peer-to-Peer  Information  Systems  Statement  of  Work,  HP  OpenView  has  been  chosen 
as  one  of  the  network  management  platforms  that  will  be  used  in  the  peer-to-peer  prototype 
system. 

8.2.1.  Environment 

The  supported  platforms  are: 

•  HP-UX  9.x  and  10.x 

8.2.2.  Framework  Services 

Openview  is  an  open,  proprietary,  object-oriented  framework  whose  objects  are  strictly 
Managed  Object  instances.  An  object's  definition  is  a  combination  of  its  map  and  other 
graphic  representation  information  and  its  SNMP  MIB  definitions.  Integration  is  seen 
mainly  as  the  integration  of  Managed  Object  Agents  and  a  set  of  independent  applications 
driven  by  data  collected  from  the  Agents. 

8.2.3.  Event  Services 

SNMP  traps  support. 

8.2.4.  GUI 

OSF/Motif 

8.2.5.  Security 

User  ID  rudimentary  access  control. 
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8.2.6.  Contacts 

This  review  is  based  on  the  HP  OpenView  Windows  Application  Design  and  Style  Guide, 
Programmer's  Guide  and  Reference,  Programmer's  Guide  (a  separate  manual  emphasizing 
SNMP  eoneepts),  Integration  Utilities  and  the  OpenView  Network  Node  Management  web 
pages  on  the  Developer's  Toolkits  and  Integration  Certifications  Requirements. 

*  Ginny  Johnson  617-221-5286 

*  Magali  Medina  617-238-8508 

8.2.7.  HP  References 

8.2. 7.1.  HP  OpenView  Users'  Forum  Survey 

From  INTERNETWORK  February  1996  v7  n2  pi  1(1); 

A  survey  of  members  of  the  HP  OpenView  Users'  Forum  reveals  the  high  degree  of 
frustration  of  network  managers  over  the  shoddy  customer  support  provided  by  HP. 
About  half  of  the  respondents,  however,  said  that  they  will  stay  committed  to  the 
product  for  one  to  three  years  for  various  reasons,  such  as  the  need  to  recoup 
investments  and  skepticism  about  whether  there  is  a  better  product.  The  survey  also 
noted  what  network  managers  really  want.  These  include  a  scalable  and  distributed 
architecture,  built-in  reporting  capabilities,  better  event  handling  functions  and  more 
controllable  auto  discovery,  improved  SNMP  polling  features,  easy  to  install  products, 
and  a  truly  open  network  management  system. 

The  complaints  I'm  talking  about  aren't  isolated  —  the  horror  stories  are  consistent,  told 
over  and  over  again  by  an  overwhelming  majority  of  respondents.  And  our  survey 
reached  over  one-fourth  of  the  OpenView  Forum  membership,  meaning  that  the  results 
truly  reflect  the  wider  population. 

What  do  these  managers  want  besides  better  customer  support? 

*  First  and  foremost,  a  scalable  solution  with  a  distributed  architecture  —  a  product  that 
doesn't  get  more  and  more  complicated  to  use  when  there  are  multiple  users  and 
multiple  maps. 

*  Second,  they  want  built-in  reporting  capabilities  so  they  can  make  sense  out  of  the 
data  they've  collected  without  spending  months  writing  scripts  and  feeding  data  into 
third-party  reporting  tools. 

*  Third  on  the  list  are  better  event  handling  capabilities  —  filtering,  consolidating  and 
correlating  alarms.  In  addition,  managers  want  auto  discovery  that  is  more  controllable, 
SNMP  polling  features  that  work  better,  and  products  that  are  easier  to  install. 

*  Last,  but  not  least,  they'd  like  an  open  management  system  that  is  truly  open  — 
supporting  the  ability  to  easily  write  to  an  event  log  and  trigger  events  from  a  log  —  and 
a  common  database  (a  real  relational  database)  instead  of  several  binary  flat  files. 

Is  this  too  much  to  ask?  Interestingly,  not  one  respondent  asked  for  some  pie-in-the-sky 
object-oriented  system  that  supports  CMIP  and  GDMO  modeling... 
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No  one  asked  for  the  moon  or  a  product  that  handles  everything  from  soup  to  nuts.  Just 
simple,  reliable  SNMP  data  collection,  with  information  stored  in  an  accessible  place, 
and  a  client-server  architecture  that  can  be  distributed  in  a  scalable  fashion.  Is  that 
really  too  much  to  ask? 

8.3.  Bull  ISM/OpenMaster 

(http://www.bull.com) 

(http://w3ibt.bull.fr/ism/) 

Bull  is  a  recent  arrival  in  the  U.S.  market,  but  is  strong  in  European  and  Asian  markets. 

8.3.1.  Framework  Services 

Integration  is  seen  as  a  matter  of  defining  managed  objects  in  ISO's  OSI  GDMO.  There  is  a 

client/server  architecture,  but  communication  with  components  is  CMIP-based. 

8.3.2.  Event  Services 

Supports  CMIP  events. 

8.3.3.  Contacts 

This  review  is  based  on  a  presentation  given  by  Bull  representatives  Albert  Fitussi  and 

Michael  Maloof,  and  on  the  Integrated  System  Management  Administrator's  Guide. 

Contact  information  is  as  follows: 

Michael  Maloof  (508.294.6129,  MMaloof@bull.com) 

Albert  Fitussi  (508.294.5048,  a.fitussi@bull.com) 

8.3.4.  Bull  References 

8. 3. 4.1.  Comments  from  Network  World 

¥xom.  Network  World  A^xiX  15,  1996  vl3  nl6  pl9(l): 

ISM/OpenMaster  is  a  late  arrival  in  the  US  market,  although  it  is  used  by  500 
organizations  worldwide;  it  competes  with  HP's  OpenView,  IBM's  SystemView  and 
Tivoli,  and  Computer  Associates'  CA-Unicenter. 

8.3. 4.2.  Bull/Amdahl  Agreement 

From  Communications  Week  Maxch  18,  1996  n601  p38(l): 

Abstract 

Groupe  Bull  and  Amdahl  recently  reached  partnership  agreement  that  will  dramatically 
expand  the  market  for  Bull's  ISM/OpenMaster  enterprise  management  software  suite, 
while  completing  Amdahl's  product  offerings.  The  partnership  provides  Amdahl  with  a 
complete  solution,  enabling  it  to  compete  with  recently  merged  IBM  and  Tivoli 
Systems.  The  mergers  highlight  the  necessity  of  a  strong  partnership  strategy  to  remain 
competitive  in  the  network  market.  However,  the  trend  toward  partnership  raises 
interoperability  issues.  Network  managers  cite  product  interoperability  as  the  most 
important  consideration  in  purchasing  distributed  systems  management  tools.  Many 
network  managers  have  not  yet  deployed  a  framework  for  distributed  systems 
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management,  even  though  over  half  of  the  network  managers  responding  to  a  reeent 
survey  reported  that  they  would  ehoose  HP's  OpenView.  A  elear  winner  in  the  network 
market  is  yet  to  emerge. 

Full  Text 

Two  weeks  ago,  I  received  a  call  from  a  PR  person  who  wanted  to  set  up  a  time  for  me 
to  speak  with  executives  from  Amdahl  Corp.  about  its  distributed  systems  management 
strategy.  My  first  reaction  was:  "What  distributed  management  strategy?"  I  wasn't 
aware  that  the  company  that  made  a  name  for  itself  by  giving  IBM  a  run  for  its  money 
in  the  mainframe  market  had  a  strategy.  It  does. 

The  foundation  of  that  strategy  is  a  five-year,  renewable  partnership  with  Groupe  Bull 
to  market  the  Paris  computer  vendor's  ISM/OpenMaster  enterprise  management 
software  suite  worldwide.  The  pact  makes  sense  for  both  companies.  Bull  gains  access 
to  Amdahl's  customers  on  this  side  of  the  Atlantic  as  well  as  its  sales  force. 

Amdahl,  concerned  about  what  type  of  an  impact  an  IBM-Tivoli  union  is  likely  to  have 
on  its  customer  base,  now  has  a  comprehensive  solution  that  manages  PCs,  work 
groups,  Unix  systems,  mainframes,  data  and  voice  networks  as  well  as  enterprise-wide 
security  and  database  systems. 

The  Amdahl-Bull  deal,  following  on  the  heels  of  the  IBM-Tivoli  merger,  further 
exemplifies  that  no  vendor  can  survive  in  today's  complex,  distributed  networking 
world  without  a  strong  partnership  program  or  strategy. 

But  as  companies  form  partnerships,  network  managers  are  increasingly  concerned 
with  how  well  the  products  interoperate  with  each  other.  A  recent  survey  of  more  than 
700  IS/network  managers  conducted  by  Boole  &  Babbage  revealed  that  most  important 
criterion  for  evaluating  distributed  systems  management  products  is  interoperability. 

The  level  of  interoperability  between  products  from  different  vendors  is  the  most 
important  criterion  for  buying  DSM  tools,  said  Saverio  Merlo,  senior  vice  president  of 
marketing  at  Boole  &  Babbage,  a  provider  of  management  software.  The  second  most 
important  is  scalability  and  the  third  is  vendor  support. 

Another  important  survey  finding  was  relatively  few  respondents  had  deployed  a 
framework  for  distributed  systems  management  in  their  organizations.  Deploy  means 
actually  using  that  platform  throughout  an  organization. 

When  the  managers  were  asked  which  framework  they  had  chosen,  not  deployed,  54 
percent  said  Hewlett-Packard's  HP  OpenView  would  be  their  building  block. 

Though  it  might  seem  that  OpenView,  the  market  leader  in  the  enterprise  management 
arena,  won  the  contest,  the  race  is  not  over.  OpenView  has  a  commanding  lead,  but 
indications  are  that  the  fastest-growing  net  management  platform  is  IBM's  NetView  for 
AIX.  It  remains  to  be  seen  what  type  of  impact  IBM-Tivoli  will  have  on  the  distributed 
systems  management  market.  And  others  are  jockeying  for  position. 


8.4.  Cabletron  Spectrum 

(http://www.cabletron.com/) 

(http://www.cai.com/products/uctr.htm) 
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Cabletron's  Spectrum  product  has  been  widely  acclaimed  in  industry  publications  for  the 
intelligence  of  its  network  trouble  shooting  strategy.  Cabletron  has  put  particular  emphasis 
on  the  problem  of  isolating  the  root  cause  of  a  network  problem,  such  as  a  failed  line  or 
router,  from  the  hundreds  or  thousands  of  related  failure  reports  that  a  single  point  failure 
may  cause.  However,  as  Cabletron  is  a  major  provider  of  network  hardware,  such  as 
routers,  it  is  more  focused  on  providing  network  management  tools  for  its  own  hardware, 
than  on  providing  a  truly  open  architecture  suitable  for  supporting  third  party  applications. 

8.4.1.  Environment 

Spectrum  is  available  on  at  least  the  following  platforms: 

•  HP/UX  10.01  on  HP9000 

•  Solaris  2. 4/2. 5  on  Sparc 

8.4.2.  Framework  Services 

The  SPECTRUM  system  is  officially  unbundled  to  provide  users  and  developers  with 
components  and  toolkits.  The  two  primary  components  of  the  SPECTRUM  product  are  the 
SpectroSERVER,  which  communicates  with  the  managed  devices,  and  the  SpectroGRAPH 
client,  which  provides  the  user  interface  graphical  display  functions.  The  SpectroSERVER 
contains  a  modelling  engine,  called  the  Virtual  Network  Machine  (VNM),  an  object- 
oriented  database  (OODB)  and  a  multi-product  Device  Communication  Manager  (DCM) 
for  communicating  with  managed  devices. 

The  SpectroSERVER  communicates  with  the  SepctroGRAPH  client  via  the 
SpectroSERVER  API  (SSAPI).  The  SSAPI  is  implemented  in  a  separately  available  toolkit 
which  provides  third-party  applications  with  an  interface  to  the  data  maintained  in  the 
SPECTRUM  database  and  managed  devices.  In  order  to  employ  a  model  and  export  it,  the 
developer  must  register  hardware-address-founded,  MIB-based  model  definitions  with 
Cabletron.  The  model  definition  is  similar  to  the  CORBA  interface  definition  and  database 
schema  combined.  It  is  used  to  communicate  management  information  internally  and  to 
make  it  persistent  by  storing  it  in  a  Sybase-based  database.  There  is  a  Model  Type  Editor 
toolkit  available. 

The  SpectroServer  API  is  a  published,  but  proprietary  interface.  The  API  is  not  CORBA 
compliant,  but  Cabletron  expects  to  release  a  CORBA-compliant  API  within  the  year. 

The  Device  Communication  Manager,  which  is  part  of  the  SpectroSERVER,  is  the 
component  that  communicates  with  managed  devices.  It  supports  GETs  and  SETs  via 
SNMP,  RPC,  and  IPC.  In  addition,  there  is  an  External  Protocol  Interface  (EPI)  to  the 
Device  Communications  Manager  that  can  be  used  to  write  applications  which 
communicate  with  devices  through  non-standard  protocols.  Editors  and  toolkits  are 
available  to  facilitate  building  access  to  new  network  components. 

The  interfaces  to  the  rule-based  configuration  and  topology  engine  in  the  VNM  include  the 
Inference  Handler  API  and  the  Command  Eine  [User]  Interface  which  allows  simple  rule 
definitions. 

There  is  no  replication  of  model  data  between  VNMs,  although  the  alarms  triggered  by 
events  are  distributed  via  the  proprietary  Distributed  Data  Manager  (DDM).  This  manager 
combines  a  20:1  compression  ratio  with  TCP/IP  transport  to  ensure  that  all 
SpectroGRAPH  clients  are  notified  with  minimum  impact  on  the  network. 
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The  heart  of  the  VNM  is  the  NetMap-like  Virtual  Network  Maehine  in  whieh  the 
eomponents  are  eonneeted  aeeording  to  defined  and  inferred  relationships  based  on 
hardware  addresses.  VNM  topologies  ean  be  saved  as  an  open,  proprietary  info-base 
format,  whieh  is  the  only  import  format.  The  topologies  are  also  exportable  in  a  number  of 
formats  ineluding  ASCII  fdes,  Sybase,  and  Oraele. 

Configuration  fields  in  a  MIB,  sueh  as  the  eonfiguration  fields  used  by  routers,  ean  be 
defined  in  a  speeial  Configuration  Manager  paekage  and  both  saved  and  downloaded  to 
managed  systems. 

8.4.3.  Interoperability  with  HP  OpenView 

Interoperability  with  HP  OpenView  is  aehieved  via  a  Speetrum  Element  Manager  (SPEL) 
Gateway,  whieh  will  be  available  as  a  produet  at  the  end  of  Deeember  1997.  However, 
Cabletron  does  not  intend  to  support  this  produet. 

8.4.4.  Event  Services 

Events  and  Traps  are  seen  as  symptoms  and  are  not  propagated  by  the  VNM  framework, 
unless  they  pass  through  the  primary  filters,  at  whieh  point  they  are  eonsidered  Alarms. 
This  event  handling  is  part  of  Speetrum's  efforts  to  isolate  network  failures  and  minimize 
reporting  of  multiple  events  and  traps  due  to  a  single  point  of  failure.  Events  are  easily 
exported  from  the  VNM,  but  importing  events  is  more  diffieult.  Two  approaehes  would  be 
to  deelare  events  as  primitive  alarms  or  to  develop  a  C++  importing  wrapper  to  map  the 
events  into  a  model  definition  in  the  VNM. 

8.4.5.  GUI 

The  SpeetroGraph  elient  is  an  Xwindows/Motif  eompliant  GUI.  There  is  also  a  eommand 
line  interfaee. 

8.4.6.  Security 

Aeeording  to  the  Speetrum  Administrator's  Referenee  Manual,  seeurity  in  Speetrum  is 
primarily  an  aeeess  eontrol/authorization  seheme  similar  to  the  SNMP  V2  eoneept.  It 
requires  additional  erypto  and  network  seeurity  serviees  to  provide  authentieation,  privaey, 
and  data  integrity. 

8.4.7.  Contacts 

This  review  is  based  on  a  presentation  and  demo  given  by  Cabletron  on  November  6,  1996, 
the  Configuration  Guide  for  Spectrum  Enterprise  Management  d.ORevO,  SPMAs  2.1, 
Spectrum  Element  Manager  1.01  and  StackView  1.0  [June  1,  1996]  and  other 
doeumentation  as  noted. 

•  Matthew  Palis  (603.337.2145) 

•  Earry  Benson 

•  Carmelita  Eawrenee  (olawrenoe@oomailpo.otron.oom,  603.337.1489)  -  visit 
ooordinator 


28 


8.5.  Computer  Associates  International  Inc.  CA-Unicenter 

(http://www.cai.com) 

(http://www.cai.com/products/uctr.htm) 

CA-Unicenter  is  the  seeond  largest  eomputer  software  company  in  the  world  (from 
Software  Magazine,  April,  1996).  Digital  Equipment  Corporation  reeently  sold  their 
Polycenter  teehnology  for  network  management  to  CA-Unieenter. 

8.5.1.  Environment 

CA-Unieenter  is  supported  on  at  least  the  following  platforms: 

•  HP-UX  9.x  and  10.x 

•  Solaris  2.3,  2.4  and  2.5 

8.5.2.  Framework  Services 

Interoperability  with  OpenView  is  aehieved  by  including  a  licensed  copy  of  the  OV 
Operations  Center  and  the  SNMP  Platform,  or  for  CAEs  TNG  (The  Next  Generation), 
using  the  Software  Developer's  Kit  (SDK),  and  using  the  World  View  API.  Objeets  are 
defined  in  the  proprietary  Common  Object  Repository  of  the  Enterprise  (CORE)  via  the 
Class  Wizard  tool  and  the  Enterprise  Management  API  (whieh  has  multiprotoeol  data 
transport). 

TNG  is  not  CORBA  eompliant  although  it  claims  to  be  open  and  CORBA  is  listed  under 
the  Adoption  of  Standards  on  the  CA-Unicenter  feature  ehecklist.  Applieation  developers 
have  to  use  the  World  View  API  to  define  interfaees,  not  IDE,  aecording  to  the  CA- 
Unicenter  TNG  paper  by  Dr.  Elizabeth  Niehols. 

8.5.3.  Event  Services 

The  Event  Manager  is  eentral  event  console  with  distributed,  filtered  input  events.  A 
proprietary  Common  Communieations  Interface  is  used  to  transport  the  events  to  the  Event 
Manager. 

The  OV  Intelligent  Agent  can  send  events  to  the  Event  Manager. 

8.5.4.  GUI 

OSE/Motif  for  eurrent  version. 

Virtual  reality  business  proeess  simulation/model  for  TNG. 

8.5.5.  Security 

Kerberos  API,  plus  authorization  and  ACEs;  eomplies  with  National  Computer  Seeurity 
Center  Green  Book  rules. 

8.5.6.  Contacts 

This  review  is  based  on  diseussions  with  Claudia  Peters,  the  Eaulkner  Information  Services 
report  prepared  for  CAI,  the  CA-Unieenter  TNG  Software  Development  Kit  broehure,  and 
other  marketing  brochures  as  noted  (reeeived  from  Riek  Sehrader). 

•  Claudia  Peters  (617.251-5538)  is  the  teehnical  contact. 
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•  Rick  Schrader  (703.709.4762)  is  the  sales  rep  for  Army  related  projects. 

•  John  Petracek  (703.709.4590)  is  our  new  sales  rep  and  the  sales  rep  for  Air  Force 
related  projeets.  petracek@mnsinc.com 

•  Kyle  Hodges  (516.342.2376)  is  the  original  marketing  contact  assigned  to  us. 

8.5.7.  CA  References 

Digital's  POLYCENTER  technology  has  been  acquired  by  CA-Unicenter 
CA-Unicenter  will  support  Digital's  Polycenter  customers  with  a  probable  migration  to 
CA-Unicenter  TNG  (The  Next  Generation). 

Vrom  LAN  Magazine  ,  August  1996,  vll  n8  pl8(l): 

Computer  Associates  (CA,  Islandia,  NY)  has  made  it  official:  Its  eagerly  awaited  CA- 
Unicenter  TNG  is  shipping  and  will  be  hitting  the  market  six  months  ahead  of  the 
scheduled  ship  date  of  early  1997... 

This  successor  to  CA's  enormously  popular  Unicenter  product  includes  many  new 
features  and  tools  that  provide  management  funetionality  for  every  enterprise  network 
resource,  including  databases  and  applications.  "This  is  the  only  product  that  focuses 
on  managing  processes  from  end-to-end— mainframe  to  Internet  and  back"  Kumar  says. 

The  product  does  this  managing  through  Jasmine,  an  architecture  based  on  CA's  object- 
oriented  database  for  multimedia  applications.  Through  this  model,  information  about 
resources  ean  be  stored  and  monitored,  allowing  administrators  to  keep  better  track  of 
widely  distributed  systems.  This  arehitecture  also  provides  an  open,  extensible 
environment  that  is  highly  scalable  and  customizable. 

Beeause  of  its  single,  centralized  repository,  Unicenter-TNG  manages  everything  from 
one  console,  regardless  of  the  platform.  It  also  supports  the  major  network 
management  products,  including  HP  OpenView,  Sun  Net  Manager,  and  Cabletron's 
Spectrum. 

The  product  also  includes  a  three-dimensional  user  interface,  creating  an  intuitive  view 
of  system  resources,  including  hardware,  software,  security,  databases,  and  Internet 
resources. 
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8.6.  Sun  Solstice  Enterprise  Manager 

(http://www.sun.com) 

(http://www.sun.com/solstice/em-products/network/ent.man.html) 

Solstiee  Enterprise  Manager  Version  2.0  supereeeds  and  ineorporates  the  earlier  SunNet 
Manager,  Site  Manager  and  Domain  Manager.  The  Solstiee  Enterprise  Manager  can  be 
unbundled  into  server  and  elient  (user  interface)  eomponents.  The  server  component 
supports  third  party  applieations  through  the  portable  management  interfaee  (PMI)  whieh 
is  based  on  CMIP  over  TCP/IP.  Sun  plans  to  provide  a  Java  management  API  to  their 
server  by  next  spring,  but  they  have  no  plans  for  supporting  a  CORBA  interfaee  for  third 
party  applieations. 

8.6.1.  Environment 

The  supported  platforms  are: 

•  Solaris  2.4  or  2.5 

8.6.2.  Framework  Services 

Solstiee  Enterprise  Manager  is  based  on  teehnology  aequired  from  Netlabs,  Ine.  The 
Enterprise  Manager  ineludes  server  and  client  eomponents.  The  server  component 
eommunieates  with  the  managed  deviees  and  with  the  elient  eomponent;  the  client 
eomponent  provides  the  user  interfaee.  Third  party  applieations  ean  interfaee  to  the  server 
using  the  same  protoeol  as  is  used  by  the  Solstiee  Enterprise  client  and  server  eomponents. 
This  interfaee  uses  CMIP  over  TCP  (CMOT)  based  and  is  not  CORBA  eompliant.  A  Java 
interfaee  should  be  available  in  Q3  '97,  but  there  are  no  plans  to  support  a  CORBA 
interfaee  to  the  server.  The  Enterprise  Manager  includes  proprietary  objeet  definition 
interfaees  and  installation  tools  (GDMO  compliler,  RPC  CMOT  transport).  The  Enterprise 
Manager  is  Omnipoint  eompliant. 

The  instanee  repository  is  hierarohieally  structured  (MOIs  are  assigned  to  a  manager  who 
in  turn  ean  be  assigned  to  a  manager).  However  two  Management  Information  Systems 
(MIS)  ean  aet  as  reeiproeal  managers/agents  for  eaeh  other. 

The  API  (for  third  party  applieations  is  GDMO/CMIS  based. 

8.6.3.  Event  Services 

The  RequestDesigner  (part  of  the  Nerve  Center)  is  a  tool  used  to  define  an  event  filter  and 
assign  an  aetion  to  be  launehed  on  mateh. 

8.6.4.  GUI 

The  Enterprise  Manager  ineludes  a  Motif-eompliant  user  interfaee. 

8.6.5.  Contacts 

This  review  is  based  on  a  presentation  by  and  diseussion  with  Tom  Bialaski  and  Bob 
Ganley  on  12  Nov  1996  and  on  the  What's  new  in:  Solstice  Enterprise  Manager  1.2 
Developer's/OEM  Release  notes.  [Eeb  29,  1996] 

Contaet  information  is  as  follows: 

Tom  Bialaski,  Systems  Engineer  (508.442.0577),  tom.bialaski@east.sun.eom 
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Bob  Ganley,  Senior  Account  Manager  (508.442.0352),  robert.ganley@east.sun.com 

8.6.6.  Sun  References 

8. 6. 6.  l.Sun  Solstice  Enterprise  Manager 
(http://www.sun.com/solstice/em-products/network/ent.man.html) 

Solstice  Enterprise  Manager  shares  common  technology  with  SolsticeTM  Domain 
Manager TM,  SolsticeTM  Site  ManagerTM,  and  SolsticeTM  SunNet  Manager TM. 
Applications  and  agents  written  to  the  Solstice  SunNet  Manager  (SNM)  APIs  will  run 
on  Solstice  Enterprise  Manager.  With  SolsticeTM  Cooperative  ConsolesTM  receiver 
included,  it  can  receive  management  information  sent  by  Solstice  Domain  Manager, 
Solstice  Site  Manager,  or  Solstice  SunNet  Manager  thereby  enabling  it  to  act  as  a 
manager  of  managers  in  a  network  management  hierarchy. 

9.  Innovative  COTS  Systems 

In  addition  to  the  market  share  leaders,  we  have  researched  companies  with  smaller  market 
share,  but  innovative  solutions,  notably  SMARTS  InCharge. 
(http://www.smarts.com/company.html) 
(http://www.smarts.com/products/incharge_datasheet.html) 

InCharge  is  one  of  the  few  management  platforms  that  can  efficiently  correlate  large 
numbers  of  symptoms  into  probable  causes.  InCharge  uses  a  patented  algorithm  based  on 
coding  theory  to  lookup  problem  causes  based  on  the  current  set  of  symptoms.  This  gives  a 
(claimed)  performance  improvement  of  a  factor  of  100  over  other  systems,  i.e.  1000 
symptoms/sec  versus  10  symptoms/sec  (Tivoli). 

The  InCharge  platform  works  as  follows:  Raw  information  is  collected  from  devices  using 
SNMP,  CORBA,  or  a  user  supplied  interface.  The  raw  data  is  compared  against  thresholds 
to  generate  symptoms.  All  the  symptoms  are  input  into  the  correlating  engine  to  determine 
any  problems.  Problems  can  be  sent  up  a  hierarchy  of  InCharge  platforms  to  the  ultimate 
Network  management  applications,  such  as  a  trouble  ticket  or  network  map  application. 

BBN  is  using  SMARTS  InCharge  as  part  of  a  Related  DARPA  project,  DIRM. 

10.  Standards  Organizations 

10. 1.  Distributed  Management(disman)  group  of  the  IETF  (Internet 
Engineering  Task  Force) 

(http  ://www.  ietf  org/html.  charters/ disman-charter.html) 

10.2.  The  iEEE  Communications  Society  (iEEE  ComSoc) 

(http  ://engine .  ieee .  org/c  omso  c/) 

10.3.  The  internationai  Federation  for  information  Processing  (iFiP) 

(http  ://www.  ifip .  or.  at/) 

10.4.  EWOS 

(http://www.ewos.be/index.htm) 
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EWOS  is  a  European  forum  of  users,  manufacturers,  implementors  and  procurers,  working 
to  achieve  openness  in  Information  and  Communications  Technologies.  They  publish  a 
Guide  to  Open  Systems  Specifications:  Systems  and  Network  Management  Technologies 
(http://www.ewos.be/nm/gmtech.htm). 

10.5.  Network  Management  Forum 

(http://www.nmf  org ) 

NME  exists  to  promote  and  accelerate  the  worldwide  acceptance  and  implementation  of  a 
common,  service-based  approach  to  the  management  of  networked  information  systems.  A 
non-profit  corporation,  NME  is  funded  by  its  members,  including  organizations  that 
consume  information  and  telecommunications  services,  organizations  that  provide 
networked  services,  and  organizations  whose  telecommunications  and  computing  products 
are  used  to  create  services. 

The  Network  Management  Eorum  recently  announced  that  it  was  realigning  its  work 
programs  in  this  press  release. 

NME  Realigns  Work  Programs  to  Match  Investment  Trends 
All  deliverables  to  carry  NME  brand  name 

Barcelona,  Spain,  October  29,  1996.  NME  today  announced  a  restructuring  of  its  work 
in  order  to  remain  closely  aligned  with  the  investment  priorities  of  service  providers 
and  product  developers.  Work  programs  will  now  be  grouped  into  three  focused  areas: 
service  management,  network  management  and  platforms  &  technology.  The 
agreements,  specifications  and  outputs  from  NME  have  also  been  restructured,  to 
permit  faster  publication  to  the  industry. 

"Part  of  NME's  success  has  always  been  our  willingness  to  regularly  tune  programs  as 
market  requirements  evolve  and  to  quickly  adapt  as  competitive  pressures  impact 
members'  priorities,"  commented  Keith  Willetts,  NME  President.  "Although  we  have 
been  working  in  all  three  areas  for  some  time,  they  have  not  always  had  equal  priority. 
These  changes  should  significantly  improve  NME's  effectiveness  and  make  it  easier  for 
developers  and  implementors  to  find  the  integrated  solutions  they  require." 

Recent  focus  groups  conducted  by  NME  indicated  three  major  areas  where  service 
providers  are  making  significant  investment  in  management  systems: 

•  Improving  process  flow-through  to  achieve  service  management  excellence; 

•  Managing  an  enlarging  network  infrastructure  to  meet  rising  demand  for 
bandwidth, 

•  Migrating  from  proprietary,  legacy  systems  to  integrated,  "off-the-shelf  distributed 
computing  platforms. 

In  the  area  of  Service  Management,  NME  will  continue  to  play  a  lead  role,  as  it  has 
since  introducing  its  SMART  program  two  years  ago.  Based  on  this  work,  service 
providers  have  identified  areas  where  industry  agreements  are  needed  to  achieve 
process  flow-through  —  particularly  in  areas  such  as  global  alliances  and  Internet 
Service  Providers.  Six  teams  are  active  in  the  service  management  area,  addressing 
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issues  such  as  trouble  ticketing,  performance  reporting,  ordering,  service  configuration, 
and  billing. 

Network  management,  the  starting  point  of  NMF  in  1988,  has  continued  to  evolve. 
Initially  the  main  driver  for  network  management  standards  was  supplier  independence 
but  today,  the  ability  to  manage  efficiently  across  multiple  networking  technologies  is 
the  critical  requirement.  Work  done  by  other  groups,  to  address  the  management  of 
ATM,  Frame  Relay  and  SDH/SONET,  has  to  be  integrated  in  order  for  service 
providers  to  achieve  the  service  flexibility  they  need  to  stay  competitive. 

In  its  Platforms  &  Technology  program,  NMF  will  merge  two  parallel  activities:  the 
definition  of  distributed  computing  platforms  (known  as  SPIRIT),  and  the  definition  of 
management  middleware  specifications,  including  interworking  specifications  and 
development  tools.  By  bringing  these  together,  NMF  members  should  be  better  able  to 
apply  "off-the-shelf  technology  to  management  systems. 

With  clarification  of  its  work  programs,  NMF  is  also  making  changes  to  the  way  it 
publishes  its  agreements  and  specifications,  and  the  names  they  are  given.  In  the  past, 
outputs  bore  the  name  of  the  program  that  produced  them  (such  as  OMNIPoint),  all 
deliverables  will  now  be  marketed  under  the  NMF  name.  Each  document  will  also  be 
clearly  labeled  as  to  the  subject  matter  that  it  covers. 

Three  types  of  deliverables  will  come  from  NME's  Service  Management  and  Network 
Management  programs:  NMF  Requirements  specifications,  NMF  Design  and  Analysis 
specifications,  and  NMF  Solution  Sets.  Requirements  documents,  which  will  now  be 
made  available  to  non-members,  spell  out  the  business  agreements  for  exchanging 
management  information.  Design  and  Analysis  documents,  detail  an  implementation- 
neutral  Information  Model  that  can  be  implemented  in  multiple  standards 
environments.  Solution  Sets,  introduced  in  1995,  capture  implementation-specific 
technical  interface  specifications,  removing  all  options  and  virtually  guaranteeing 
interoperability  between  implementing  systems.  Six  Solution  Sets  (released  under  the 
OMNIPoint  name  in  1995)  have  been  introduced  with  more  expected  in  early  1997. 

Two  types  of  deliverables  will  come  fromNMF's  Platforms  &  Technology  program. 
The  SPIRIT  specification,  which  is  jointly  sponsored  by  NMF  and  X/Open,  will  retain 
its  name,  and  will  continue  to  be  updated  as  service  providers  endorse  the  use  of 
market-available  computing  standards.  NMF  Component  Sets,  also  introduced  in  1995, 
provide  detailed  management  middleware  specifications.  Four  Component  Sets  (also 
released  under  the  OMNIPoint  name)  are  already  available,  and  two  more  are  expected 
to  complete  shortly. 

"Taken  together,  these  changes  will  enable  us  to  provide  highly  specific  solutions  in 
areas  where  the  industry  requires  a  standards-based  solution  while  providing  a  clear 
and  consistent  name  to  the  market,  "  explained  Elizabeth  Adams,  NME  Managing 
Director. 

NME  is  a  non-profit,  global  consortium  providing  the  communications  industry  with  a 
forum  for  developing  open,  integrated  solutions  for  managing  large,  complex  networks. 
NME  offers  a  range  of  programs,  publications  and  specifications  that  make  it  easier  for 
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companies  to  reduce  costs,  improve  service  quality  and  introduce  new  products  and 
services  faster. 

Over  180  of  the  world's  leading  service  providers,  equipment  suppliers,  software 
developers  and  private  network  operators  from  28  countries  work  together  as  NMF 
members. 


1 1 .  Vendors’  user  groups  and  partnerships 

11.1.  HP  Open  View  Forum 

(http://www.hp.com/nsmd/ov/main.html) 

On  an  annual  basis,  OpenView  Forum  collects  members'  product  requirements,  asks 
members  to  rank  the  priority  of  each  requirement,  and  forwards  the  requirements  and 
rankings  to  appropriate  HP  OpenView  technology  providers  for  their  response. 

11.2.  Tivoli  10/Pius  Association 

(http://www.tivoli.com/TENPLUS) 

We  believe  the  10/Plus  Association  represents  a  watershed  in  the  management 
industry.  All  too  often  projects  fail  to  reach  their  full  potential  due  to  the  lack  of  a 
comprehensive  enterprise  management  solution.  The  problem  is,  no  single  vendor— not 
even  the  combination  of  IBM  and  Tivoli— can  solve  all  of  your  enterprise  networking 
computing  needs. 

By  working  smarter,  and  making  a  major  investment  in  cooperatively  creating  products 
and  standards  with  our  customers,  Tivoli  Systems  and  our  10/Plus  partners  are  focused 
on  changing  the  way  vendors  work  together.  These  industry-leading  partners  are 
working  jointly  with  Tivoli  to  create  a  sophisticated  level  of  integration  with  our 
network  computing  product  suite,  and  comprehensive  support  programs,  so  that  there 
can  be  no  doubt  that  the  10/Plus  Association  is  at  the  forefront  of  solving  the  real 
customer  problem  of  today— lack  of  integration. 

12.  Conferences 

The  IFIP  and  IEEE  hold  three  series  of  conferences: 

•  IM,  held  in  odd  years,  the  next  will  be  in  May  1997, 

•  NOMS,  Network  Operations  and  Management,  held  in  even  years,  and 

•  DSOM,  Distributed  Systems  Operation  and  Management,  a  small  workshop  group 
which  meets  annually,  most  recently  in  October  1996 

12.1.  iM  '97  The  Fifth  IFIP/iEE  International  Symposium  on  integrated 
Network  Management 

(http  ://engine.  ieee.  org/comsoc/IM/) 

"Integrated  Management  in  a  Virtual  World" 

May  12  -  16,  1997 


35 


...  the  fifth  biennial  IFIP/IEEE  International  Symposium  on  Integrated  Network 
Management.  The  theme  for  1997  is  Integrated  Management  in  a  Virtual  World, 
foeusing  on  the  pivotal  role  that  integrated  network  management  plays  in  worldwide 
information  networks  and  distributed  systems  that  eross  geographieal  and  politieal 
boundaries.  Indeed,  these  networks  extend  beyond  physieal  boundaries  to  support 
virtual  eorporations,  virtual  LANs,  inter-enterprise  internetworking,  real  and  virtual 
serviee  management,  outsoureing  and  eleetronie  eommeree.  This  premier  Symposium 
eontinues  the  highly-regarded  series  sponsored  by  lEIP  Working  Group  6.6  on 
Network  Management  and  the  IEEE  Communieations  Soeiety  Committee  on  Network 
Operations  and  Management....  This  program  addresses  the  inereasing  interest  in 
overall  management  solutions  aeross  all  types  of  networks,  enterprise  eommunieation 
systems,  distributed  eomputing  systems  and  applieations. 

History  of  the  lEIP/IEEE  Symposium  on  Integrated  Network  Management  (IM) 

Known  by  the  aeronym  "ISINM"  until  this  year's  ehange  to  "IM,"  whieh  is  mueh  easier 
to  say,  this  eontinues  to  be  the  premier  biannual  industry  event  for  Network  Managers. 

Sinee  1989,  the  Symposium  has  provided  a  eentral  teehnieal  exehange  forum  for  the 
researeh,  standards,  development,  systems  integrator,  vendor  and  user  eommunities  in 
network  management.  With  the  global  information  infrastrueture  growing  at  an 
exponential  rate,  IM  '97  promises  to  build  on  the  sueeesses  of  previous  symposia  and 
provide  a  unique  opportunity  for  exploring  integrated  management  solutions  with  a 
diverse  international  eommunity. 

The  symposium  series  has  demonstrated  inereasing  interest  in  overall  management 
solutions  aeross  all  types  of  networks,  enterprise  eommunieation  systems,  distributed 
eomputing  systems  and  applieations.  Sueh  eomprehensive  network  management  is  of 
eontinued  interest  for  the  next  symposium;  integrating  data  and  teleeommunieation 
networks,  from  narrowband  to  broadband,  terrestrial  to  satellite,  fixed  to  mobile,  used 
for  eornmon  as  well  as  advaneed  multi-media  eommunieation. 

Beginning  with  our  first  symposium  in  1989,  eaeh  ISINM  program  and  its  related 
theme  has  refieeted  the  historie  events  in  integrated  network  management,  indeed  has 
helped  shape  them. 

1989;  Improving  Global  Communieation  Through  Network  Management 

When  we  held  the  first  ISINM  in  Boston  in  1989,  the  need  for  eomprehensive  network 
management  eapabilities  was  apparent  after  major  disasters  had  oeeurred  in  the 
teleeommunieations  industries  in  the  years  before.  Standards  for  enabling  integrated 
network  management  aeross  multiple  vendor  networking  resourees  were  in  the  heat  of 
development  in  international  and  regional  arenas.  While  some  thought  that  developing 
these  standards  was  the  most  diffieult  path  on  the  road  to  integrated  management 
solutions,  many  realized  a  few  years  later  that  standards  were  the  beginning  of  a  long 
journey.  Integrated  network  management  emerged  to  be  one  of  the  most  eomplex  and 
hard  to  solve  problems  of  our  heterogeneous  eommunieations  eommunity. 

1991;  Worldwide  Advanees  in  Integrated  Network  Management 

After  two  years,  when  we  held  the  seeond  ISINM  in  Washington,  D.C.,  the  need  for 
enterprise-oriented  management  aeross  data  and  teleeommunieations  applieations  and 
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distributed  systems  became  increasingly  apparent.  Principle  problems  related  to 
incorporating  standards  into  products  aimed  at  providing  coherent,  integrated  network 
management  solutions  across  future,  standards-based,  multi-vendor  components  as 
well  as  existing  proprietary  components.  Multi-vendor  demonstrations  in  North 
America,  Europe  and  Japan  seemed  to  indicate  that  the  time  had  come  when  users 
could  competitively  procure  network  management  products  in  any  of  several  countries 
and  be  confident  that  they  would  interoperate  with  comparable  products  in  other  world 
regions.  That  wasn't  so. 

1993;  Strategies  For  The  Nineties 

We  have  learned.  We  are  not  at  the  end  of  the  road  -  we  are  not  even  in  the  middle.  We 
are  only  at  the  beginning  and  will  remain  there  probably  for  the  greater  part  of  the 
nineties.  Worldwide  coordinated  strategies  are  needed  to  evolve  integrated  network 
management  in  the  best  way.  The  beginning  of  the  nineties  was  characterized  by  big 
political,  ecological  and  technical  changes  in  all  areas  worldwide.  The  exponential 
growth  of  internetworking  in  general  and  new  multimedia  applications  based  on 
broadband  and  mobile  network  technology  will  remain  the  driving  forces  of  the 
communications  area. 

However,  the  element  of  uncertainty  plays  a  dominant  role  in  all  environments.  Down¬ 
sizing  and  up-sizing  in  volume  and  time  requires  flexibility  to  change.  These  problems 
are  intensified  by  economic  and  regulatory  constraints,  problem  complexity, 
technology  advances,  standards  development,  product  introductions,  market 
requirements,  user  demands  and  other  factors  which  change  unpredictably  over  time. 

A  paradigm  shift  took  place  during  these  phases:  network  management  systems  used 
for  crisis  situations  in  the  past  evolved  to  powerful  tools  for  the  day-to-day 
management  of  systems,  services,  applications  and,  of  course  networks. 

1995:  Rightsizing  in  the  Nineties 

During  this  sometimes  turbulent  period  of  rightsizing  in  all  areas,  the  need  for 
management  systems  is  greater  than  ever  before.  Management  is  a  fundamental  part  of 
a  reliable  information  infrastructure.  It  assures  the  correct,  efficient  and  mission- 
directed  behavior  of  the  hardware,  software,  procedures  and  people  that  use  and 
provide  all  the  information  services.  Effective  management  of  the  information 
infrastructure  is  becoming  as  essential  as  marketing  and  selling  products.  In  addition,  it 
helps  to  raise  customer  satisfaction.  Integrated  network  management  belongs  to  the 
enabling  technologies  of  a  worldwide  information  infrastructure. 

12.2.  DSOM,  October  28-30,  1996 

(http://www.cselt.stet.it/CNOMWWW/DSOM.html) 

The  workshop  is  sponsored  by  the  International  Federation  for  Information  Processing 
(IFIP)  Working  Group  6.6  on  Network  Management  for  Communication  Networks 
with  technical  co-sponsorship  by  the  IEEE  Communications  Society  Technical 
Committee  on  Network  Operations  and  Management  (CNOM). 

The  workshop  is  an  effort  to  bring  together  people  actively  working  in  the  Distributed 
Systems  Management  area.  The  workshop  attendance  is  limited  to  100  participants. 
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The  scope  of  this  workshop  will  be  on  the  operations  and  management  of  application 
software  or  services  within  a  distributed  system  and  the  impact  of  advanced  computing 
and  network  technologies  on  management. 

The  "hot  topic"  theme  of  this  workshop  will  be  on  "Intelligent  Agent  Technology  for 
Management  of  Distributed  Systems"  with  papers  distributed  over  3  sessions.  Recent 
trends  in  distributed  processing  is  to  make  use  of  intelligent  agents  which  interpret  a 
scripting  language  such  as  TCL  or  Java  which  enables  sophisticated  new  management 
functions  to  be  loaded  into  existing  management  agent  interpreters.  A  variation  on  this 
concept  is  the  use  of  mobile  agents  which  move  around  the  network  performing  actions 
on  behalf  of  users  (managers).  As  new  technologies  become  available  and  market  pull 
is  getting  strong  new  management  paradigms  are  being  proposed  and  they  will  be 
discussed  at  the  Workshop. 

The  workshop  will  also  explore  the  problems  and  issues  relating  to  the  use  of  dynamic 
programming  concepts  for  intelligent  agents  in  managing  distributed  systems,  but  will 
also  provide  papers  on  other  topics  related  to  distributed  management,  such  as: 

•  Experiences  with  Distributed  Management  of  Applications  and  Services. 

•  Coping  with  Management  of  Large  Scale  Distributed  Systems 

•  Cooperative  Management 

•  Quality  of  Service  in  Distributed  Systems  and  Networks 

•  Data  Management  in  Distributed  Environments 

•  Standardization  in  Distributed  Management 

•  Platforms  for  Distributed  Management 

•  Management  Policies 

•  Security  Issues 

13.  Research  Projects 

13. 1.  The  Simple  Group 

(http://wwwsnmp.cs.utwente.nl/~nm/) 

The  Simple  Group  is  the  network  management  research  group  of  the  'Tele-Informatics  and 
Open  Systems'  (TIOS)  group  of  the  'Centre  for  Telematics  and  Information  Technology' 
(CTIT)  of  the  'University  of  Twente'  (UT)  in  the  Netherlands.  They  maintain  the  Scotty 
(http://wwwsnmp.cs.utwente.nl/software/ut-scotty.html)  system  which  is  freely  available 
as  source  code  written  in  C  and  Tcl/Tk  for  UNIX  systems. 

Scotty  is  the  name  of  a  software  package  which  allows  to  implement  site  specific 
network  management  software  using  high-level,  string-based  APIs.  The  software  is 
based  on  the  Tool  Command  Language  which  simplifies  the  development  of  portable 
network  management  scripts.  Scotty  was  originally  developed  at  the  University  of 
Braunschweig. 
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They  also  maintain  the  SimpIeWeb  (http://wwwsnmp.es.utwente.nl/)  whieh  is  a  listing  of 
network  management  resourees,  ineluding  a  list  of  network  researeh  projeets. 
(http://wwwsnmp.os.utwente.nl/researoh/groups.html) 

Sootty  provides  aooess  to  SNMPvl  and  SNMPv2  and  a  number  of  well  known  Internet 
servioes  like  DNS,  various  ICMP  paokets,  NTP,  TCP,  UDP,  SUN  RPCs  (mount,  rstat, 
portmap)  eto.  The  tkined  network  editor  is  the  graphioal  user  interfaoe  whieh  integrates 
applioations  that  are  usually  written  as  Tel  soripts  based  on  the  sootty  Tel  extension. 
Applioations  distributed  with  the  sootty  and  tkined  souroes  inolude  network  disoovery, 
trouble-shooting  applioations,  event  filter,  SNMP  MIB  browser  eto.  An  experimental  MIB 
browser  is  also  available. 

13.2.  ARPA  ActiveNets  Project 

The  foous  of  the  NetSoript,  Aotive  Networks  and  SwitohWare  projeets  is  to  make  it  easier 
to  modify  the  underlying  oommunioations  nodes.  The  abstraots  for  eaoh  of  these  projeets 
oite  the  time  delay  (measured  in  years)  for  aohieving  oommunioations  protoool 
standardization,  and  suggest  methods  for  enhanoing  oommunioations  nodes  without  need 
for  a  long  standardization  prooess.  These  projeets  are  all  sponsored  by  ARPA  under  the 
reoently  launohed  AotiveNets  program. 

13.2.1.  Columbia  University  Management  by  Delegation  Project 

(http://www.cs.oolumbia.edu/~german/mbd.html) 

The  agent  technology  has  matured  through  a  few  generations  of  research  versions.  It 
was  licensed  by  Columbia  to  System  Management  Arts  (SMARTS),  a  DCC  lab  spin¬ 
off  company,  that  recently  announced  a  commercial  version.  This  is  the  SMARTS 
company  referred  to  in  the  "Innovative  COTS  Products"  section  above. 

13.2.2. Columbia  University  NetScript  Project 

(http://www.cs.columbia.edu/~dasilva/netscript.html) 

Netscript  is  a  programming  language  and  environment  for  building  networked  systems. 
Its  programs  are  organized  as  mobile  agents  that  are  dispatched  to  remote  systems  and 
executed  under  local  or  remote  control.  The  goal  of  NetScript  is  to  simplify  the 
development  of  networked  systems  and  to  enable  their  remote  programming. 

13.2.3.  MIT  Active  Networks  Project 

(http :  / / WWW .  tns .  Ic  s .  mit .  edu/  ac  ti  vewar  e) 

A  paper  (http://www.tns.lcs.mit.edu/publications/sospwip95.html)  was  presented  at  the 
15th  Symposium  on  Operating  Systems  Principles. 

Active  networks  allow  individual  user,  or  groups  of  users,  to  inject  customized 
programs  into  the  nodes  of  the  network.  "Active"  architectures  enable  a  massive 
increase  in  the  complexity  and  customization  of  the  computation  that  is  performed 
within  the  network,  e.g.,  that  is  interposed  between  the  communicating  end  points. 

13.2.4. University  of  Pennsylvania  and  Bell  Communications  Research 
SwitchWare  Project 

(http://www.cis.upenn.edu/~jms/SoftSwitch.html) 
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We  propose  the  development  of  a  set  of  teehnology  which  will  enable  rapid 
development  and  deployment  of  new  network  services.  The  key  insight  is  that  by 
making  the  basic  network  service  selectable  on  a  per  user  (or  even  per  packet)  basis, 
the  need  for  formal  standardization  is  eliminated.  Additionally,  by  making  the  basic 
network  service  programmable,  the  deployment  times,  today  constrained  by  capital 
funding  limitations,  are  tremendously  reduced  (to  the  order  of  software  distribution 
times).  Finally,  by  constructing  an  advanced,  robust  programming  environment,  even 
the  service  development  time  can  be  reduced. 

13.2.5.BBN  ActiveNets  Project 

As  part  of  the  ActiveNets  project,  BBN  is  working  on  the  SmartPacket  project,  which 
applies  active  network  technology  specifically  to  the  problem  of  network  management. 

13.3.  New  ARP  A  Initiative  in  Active  Networks 

ARPA  is  initiating  a  new  research  program  in  the  Active  Networks  area.  This  program  will 
focus  on  research  into  making  virtual  networks  robust,  secure,  and  dynamically  self- 
configuring,  based  on  the  requirements  of  the  distributed  application,  and  the  run-time 
capabilities  of  the  network  resources.  Managing  the  network  resources  when  both  their 
capabilities  and  capacities  are  dynamic  requires  management  access  that  is  as  low-level, 
robust,  and  dynamic  as  the  resource  objects  themselves.  One  area  of  research  that  BBN  is 
proposing  involves  a  low-level  directory  service  that  matches  the  requirements  of 
distributed  processing  management,  rather  than  using  naming  schemes  based  on  e-mail 
requirements  or  a  simple  host  name  /  IP  address. 

13.4.  Network  Management  in  a  Multi-National  Environment 

(http://www.ndfrl.af.mil/~accord/netman.html) 

This  experiment  will  develop  and  evaluate  emerging  network  management  concepts  in 
a  coalition  force  environment.  It  will  also  provide  management  of  the  ACCORD 
testbed  network,  and  support  many  of  the  experiments  using  the  network,  with 
management  and  data  collection  services. 

13.5.  ACCORD  project 

(http://www.ndfrl.af.mil/~accord/accord.html) 

ACCORD  is  a  five-nation  ATM  network  testbed  to  enable  cooperative  demonstration 
and  experimentation  of  technologies  and  ideas  relevant  to  military  Command  Control 
Communications  and  Intelligence. 

14.  Trends  and  Emerging  Technologies 

There  are  several  trends  and  emerging  technologies,  including: 

•  Web  based  management  tools  as  a  way  around  long  lead  time  protocol 
development  (See  below.) 

•  Merger  of  network  and  system  administration  for  "end-to-end"  monitoring  and 
more  emphasis  on  client  or  user  viewpoint;  for  example,  managing  video  transfer 
by  either  allocating  large  network  pipes  or,  enabling  compression  at  end  points  or 
most  interesting,  by  combination  of  both 
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•  Management  of  managers;  often  done  in  a  "proprietary"  way,  i.e.  one  manager 
provides  the  ability  for  other  managers  to  report  to  it;  not  a  peer-to-peer 
relationship 

•  Microsoft  Systems  Management  Server 
(http://www.microsoft.com/msdn/sdk/platforms/doc/backoff/bpr/src/sms_l.htm)  a 
"de  facto"  standard  for  PC  management, 

•  Each  manufacturer  has  both  LAN  and  WAN  management  products,  how  will  these 
be  integrated  in  a  "manager  of  managers"  scheme? 

•  Applications  are  driving  network  management;  the  large  (i.e.  bandwidth 
consumers)  of  the  internet  are  web  applications,  email,  manufacturing 
(CAD/CAM),  distributed  databases,  and  video;  what  are  the  application  users  and 
suppliers  in  these  fields  doing? 

•  Mobile  computing 

•  Satellite  communications 
Web-Based  Enterprise  Management 
(http://wbem.freerange.com) 

SAN  ERANCISCO  -  July  17,  1996  -  BMC  Software  Inc.,  Cisco  Systems  Inc.,  Compaq 
Computer  Corp.,  Intel  Corp.  and  Microsoft  Corp.  today  proposed  an  industry  standards 
effort  that  will  allow  administrators  to  use  any  Web  browser  to  manage  disparate 
systems,  networks  and  applications.  The  intent  of  the  Web-Based  Enterprise 
Management  effort  is  to  enable  the  development  of  tools  that  reduce  the  complexity 
and  costs  of  enterprise  management. 

In  addition,  the  effort  promotes  the  use  of  two  new  management-related  technologies  to 
provide  data  modeling,  manipulation  and  communication  capabilities  recently  outlined 
at  a  meeting  of  the  Internet  Engineering  Task  Eorce  (lETE): 

HyperMedia  Management  Schema  (HMMS),  an  extensible  data  model  representing  the 
managed  environment 

HyperMedia  Management  Protocol  (HMMP),  a  communication  protocol  embodying 
HMMS,  to  run  over  HTTP 


15.  Industry  Comments 

15. 1.  Network  Computing  Online 

(http://techweb.cmp. com:80/techweb/nc/docs/aboutnwc.html) 

Pour  of  the  top  5  vendors  (IBM,  HP,  Sun  and  Cabletron)  were  reviewed  by  Network 
Computing  Online  in  an  August  15  article  entitled 

Global  Network  Management  —  4  Platforms  Revi  ewed.  Network  Computing  Online  has 
many  corporate  sponsors  including  Cabletron,  HP,  IBM  Networking,  and  SunSoft  and 
reviews  products  in  a  network  testbed  which  includes  university  and  corporate  computing 
centers. 
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This  was  a  difficult  test  to  call  because  all  of  the  products  are  an  exeellent  foundation 
for  some  network  bias.  But  Cabletron's  Speetrum  and  HP  OpenView  NNM  proved  to 
be  the  best.  Both  have  a  fine  distributed  strategy  and  have  added  tools  and  funetions  to 
their  base  platforms.  HP  is  still  the  leader  in  open  systems  support,  while  Speetrum's 
offering  is  the  most  intelligent.  This  is  not  to  say  the  products  from  IBM  and  SunSoft 
failed.  Both  have  workable,  distributed  strategies,  and  IBM  has  some  useful  tools 
where  the  most  benefit  is  derived  from  a  eommitment  to  its  hardware  and  software 
strategy. 

15.2.  Communications  Week 

The  following  is  from  an  editorial  in  CommunicationsWeek  Aipril  8,  1996  n605  p34(l): 
Abstract 

Distributed  serviees  management  is  a  major  trend  in  1996,  with  IBM  moving  to 
integrate  the  Tivoli  Management  Environment  (TME)  network  management  platform 
with  its  own  network  management  tools  after  aequiring  Tivoli  Systems  Ine  and  HP 
rolling  out  more  pieees  of  its  Tornado  distributed-management  strategy,  sueh  as 
Network  Node  Manager  4. 1 .  These  and  other  vendors  are  moving  in  the  right  direetion 
to  offer  the  unified,  seamless  management  solutions  inereasingly  needed  on 
heterogeneous  eorporate  internetworks.  Today's  management  platforms  manage 
networks  and  systems  well  but  do  not  give  administrators  a  elear  view  of  the  overall 
effects  network  problems  will  have  on  the  enterprise.  Cabletron  Systems  Ine  may  be 
elosest  to  a  true  business-driven  enterprise  management  model  because  it  already  has  a 
sealable,  distributed  arehiteeture  in  plaee. 

Pull  Text 

If  last  year  was  the  year  of  merging  network  and  systems  management,  1996  will 
eertainly  go  down  as  the  year  of  distributed  systems  management. 

IBM  Corp.  took  the  industry  by  surprise  earlier  this  year  with  the  announeement  that  it 
was  going  to  aequire  Tivoli  Systems  Ine.  With  the  merger  eompleted,  IBM  unfolded 
the  Tivoli  road  map  last  week  at  NetWorld+Interop,  positioning  the  Tivoli 
Management  Environment  (TME)  as  the  foundation  of  its  distributed  management 
strategy. 

Hewlett-Paekard  Co.  also  rolled  out  another  pieee  of  its  Tornado  distributed 
management  strategy.  Network  Node  Manager  4.1,  giving  network  managers  the 
ability  to  distribute  a  number  of  management  funetions  aeross  their  enterprise 
networks. 

And  Cabletron  Systems  Ine.,  Roehester,  N.H.,  eontinued  to  build  on  its  distributed 
arehiteeture  by  announeing  tighter  links  with  key  systems  management  partners'  tools, 
extending  the  Speetrum  platform's  systems-administration  reach. 

Although  much  work  still  needs  to  be  done,  these  vendors— and  others— are  moving  in 
the  right  direetion.  Network  managers  are  searching  for  solutions  that  will  help  them 
effeetively  manage  the  numerous  network  deviees,  mainframes,  Unix  systems,  PCs, 
servers,  databases,  applieations  and  publie  network  serviees  that  make  up  today's 
global  networks. 
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Management  platforms  are  good  at  managing  networks  and  systems  but  ean't  really 
give  IT  managers  a  elear  view  of  what  impaet  a  failed  router  may  have  on  the 
aeeounting  department  or  some  other  business  funetion. 

In  many  eompanies,  the  move  to  distributed  applieations  and  objeet  systems  has 
already  begun.  It's  also  apparent  that  network  managers  are  going  to  require 
administration  tools  that  do  mueh  more  than  let  a  sharply  defined  window  into  their 
networks,  systems  and  applieations. 

Perhaps  Cabletron,  whieh  already  has  a  sealable,  distributed  platform,  is  pointing  the 
way  to  the  future  by  linking  enterprise  management  with  the  proeesses  that  drive  a 
eompany's  business. 

This  is  a  sign  of  things  to  eome.  Network-administration  tools  must  either  evolve  or  be 
replaeed  by  management  software  that  ean  see  beyond  network  eomponents— software 
that  ean  tie  into  a  eompany's  business  logie  and  business  proeesses. 

The  industry  is  foeused  on  the  problem  of  performanee  at  the  end-to-end  applieations  level 
(or  at  an  even  higher  level,  on  the  operation  of  whole  business  units).  However  industry 
analysts  overstate  the  eurrent  state  of  affairs.  The  abstraet  for  the  above  artiele  states: 
"Today's  management  platforms  manage  networks  and  systems  well  but  do  not  give 
administrators  a  elear  view  of  the  overall  effeets  network  problems  will  have  on  the 
enterprise." 

In  faet,  there  are  still  major  problems  in  managing  networks,  (isolating  the  initial  failure, 
determining  what  problems  are  in  faet  merely  symptomatie  of  another  failure,  and 
determining  how  to  fix  the  problem). 

15.3.  Gartner  Group 

(http ://www. eabletron. eom/ analyst-reports/ Gartner-Group/gartnerV .html  ) 

Aeeording  to  the  Gartner  Group  report  for  June,  1996,  the  following  eompanies  and 
produets  aeeounted  for  95%  of  the  market:  SunNet  Manager,  SPECTRUM,  NetView, 
OpenView  and  ISM/OpenMaster. 

SunNet  Manager  has  sinee  been  ineorporated  into  the  Sun  Solstiee  Enterprise  Manager  and 
IBM  Net  View  has  been  superseded  by  TME  from  the  new  IBM/Tivoli  group. 

15.4.  Network  Management  Market 

In  Software  Magazine,  June  1996  vI6  n6  p37(7),  there  are  several  referenees  to  the 
network  management  market: 

"Tivoli  may  have  a  good  shot  at  a  market-leading  role,  but  Computer  Assoeiates 
International  Ine.  and  Hewlett-Paekard  Co.  aren't  about  to  give  an  ineh  without  a  good 
fight." 

"Eor  example.  Computer  Assoeiates  International  now  leads  the  Unix  system 
management  software  market  with  nearly  a  21%  market  share,  aeeording  to  IDC 
(International  Data  Corp.  Eramingham,  MA)" 

"Eurthermore,  data  from  International  Data  Corp.  shows  that  HP  takes  the  lead  when  IS 
shops  are  asked  to  name  their  primary  management  platform." 
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16.  Web  Sites  for  more  information: 


16.1.  Network  Management 

http://smurfland.cit.buffalo.edu/NetMan/) 

This  server  functions  as  the  archive  base  for  comp.dcom.net-management,  as  well  as  for  a 
place  to  bring  together  references  to  other  applications  and  servers.  In  addition,  this  site 
acts  as  a  mirror  site  for  applications,  utilities  and  FAQs  pertinent  to  Network  Management. 

16.2.  SNMP  News 

(http://www.int.snmp.com) 

This  is  a  quarterly  publication  of  SNMP  Research  International.  The  first  publication  is  4th 
quarter,  1996  and  covers  such  topics  as  Web-based  Management,  and  SNMP  v2  Security. 
This  is  the  publication  of  a  single  commercial  company,  and  as  such,  will  undoubtedly 
reflect  their  perspective;  however,  this  company  has  been  involved  in  the  research 
community  for  many  years  and  newsletters  are  also  likely  to  cover  issues  of  general 
interest  to  the  community. 

16.3.  TechWeb 

(http://www.techweb.com/) 

Articles  on  technical  topics,  including  network  management.  Recent  articles  of  interest 
include  the  following: 

“Enterprise  Management  Is  Just  Around  the  Corner:”  October  15,  1995 

We  tested  some  preview  editions  of  the  next  generation  of  network  management 
products  from  SunSoft,  HP  and  Cabletron,  and  the  latest  shipping  version  from  IBM. 
Here's  what  we  found... 

“Net  Admins  Demand  Cohesive  Management”,  September  18,  1996 
“Problem  or  Solution?  —  Net  Management  and  the  ’Net”,  March,  18,  1996 

“The  Big  Picture  —  Central  control  of  distributed  nets  remains  a  work  in  progress,  but 
remote  monitoring  technology  is  starting  to  take  shape”,  July  3,  1995 
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Section  2  -  Peer  to  Peer  Information 
System  Management  Architecture 

17.  Executive  Overview 

17.1.  Identification 

This  is  the  System  Architecture  Document  for  the  Peer  to  Peer  Information  System 
Management  program.  It  is  submitted  in  fulfillment  of  requirement  4. 1.3. 4  and  as  input  to 
4.1.4;  and  CDRL  A006;  from  the  Statement  of  Work  for  the  Peer-to-Peer  Information 
System  Management  Contraet  #F30602-96C-0049. 

18.  Document  Styiistic  Conventions 

This  doeument  is  published  both  in  paper  and  hypertext  formats.  The  eross-referenees  are 
identified  inline,  external  referenees  are  eolleeted  in  an  Appendix,  On-line  References. 

18. 1.  Document  Status 

This  doeument  was  updated  on  3/27/2002  12:45  PM  by  lbob@bbn.com  (Linsey  O’Brien) 

18.2.  System  Overview 

The  Peer  to  Peer  Information  System  Management  [P2P]  is  designed  to  integrate  the 
management  of  a  variety  of  information  systems  and  their  associated  network  components, 
such  as  IP  and  ATM  devices.  This  will  be  accomplished  by  integrating  selected  existing 
management  systems,  which  will  in  turn  be  done  by  providing  optimized  communications 
mechanisms  in  a  standard  framework  enabling  the  management  systems  and  their 
applications  to  interact  as  peers.  These  interactions  include  managing  the  management 
systems  and  the  peer  communications  components  themselves.  Provisions  for  securing  the 
interactions  will  be  outlined  in  the  system  architecture  but  are  not  considered  a  primary 
requirement  of  the  P2P  project. 

18.3.  Document  Overview 

The  purpose  of  this  document  is  to  describe  the  functionality  and  architecture  of  a 
distributed  management  system  that  supports  the  requirements  of  the  Peer  to  Peer 
Information  System  Management  program.  It  will  document  all  the  major  functionality  of 
the  system  and  describe  all  the  required  interfaces,  especially  the  integrated  data 
distribution  mechanisms.  A  brief  description  of  the  contents  of  this  document  is  provided 
below. 

The  System  Overview  describes  the  high-level  functions  of  the  system  as  they  relate  to  the 
requirements  stated  in  the  Requirements  Document. 
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The  Referenced  Documents  section  lists  supporting  documents  referenced  directly  or 
indirectly  in  this  specification. 

The  System  Design  Decisions  section  covers  the  key  problems  and  issues  that  drove  the 
System  Architecture. 

The  Functional  Component  Description  takes  the  high-level  requirements  summarized  in 
the  System  Overview  and  System-wide  Design  Decisions  and  starts  the  process  of 
translating  them  into  software  design.  It  first  breaks  into  components  the  functionality 
defined  by  the  requirements.  It  then  translates  those  abstract  components  into  a  set  of 
system  objects  and  their  interactions. 

19.  Referenced  Documents 

19. 1.  Contractor  Specifications 

_  BBN  Systems  &  Technologies  Report  8180,  Nov.  1996:  Network  Management  Study 

_  BBN  Systems  &  Technologies  Report  8199,  June  1997:  Peer  to  Peer  System 
Requirements 

_  BBN  Systems  &  Technologies  Report  6986  Rev.  3.0,  Jan  1993:  Introduction  to  Cronus 

_  BBN  Systems  &  Technologies,  Cronus  Documentation,  Release  3.0,  1  December, 
1992:  Cronus  Operator  Manual© 

_  BBN  Systems  &  Technologies,  Cronus  Documentation,  Release  3.0,  1  December, 
1992:  Cronus  Operator  Manual 

_  BBN  Systems  &  Technologies,  Cronus  Documentation,  Release  3.0,  1  December, 
1992:  Cronus  User  Manual 

_  BBN  Systems  &  Technologies,  Corbus  Documentation,  Release  2.0,  April  1996: 
Corbus  Operator’s  and  Installation  Manual 

19.2.  Other  Specifications 

I.  Object  Management  Group  publication  PTC/96-03-04:  CORBA  2.0  Specification 

II.  HP  OpenView: 

A.  HP  OpenView  Network  Node  Manager  Products  Installation  Guide:  J 1 172- 
90001 

B.  HP  OpenView  Using  Network  Node  Manager:  J1 172-90003 

C.  HP  OpenView  Network  Node  Manager  Reference:  J1 172-90004 

D.  HP  OpenView  Integration  Series 

1.  Integration  Concepts:  JI 177-90000 

2.  OpenView  Windows  Application  Style  Guide:  Jl  177-90002 

3.  OpenView  Windows  Developer’s  Guide:  Jl  177-90003 

4.  OpenView  Windows  Developer’s  Reference:  Jl  177-90004 
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5.  SNMP  Developer’s  Guide  and  Reference;  J1 177-90005 

6.  Integration  Utilities:  J1 177-90006 

III.  Tivoli  TME  (Note:  Both  the  current  and  previous  component  names  are  given  in 
some  titles  as  follows  [Current  /  Former]) 

A.  Tivoli  TME  10  Application  Extension  Facility  User’s  Guide  V3.0;  GC31- 
8345-01 

B.  Tivoli  [Mid-level  Manager  /  Sentry]  Platform  User’s  Guide  V3.0;  GC31- 
8323-00 

C.  Tivoli  [Framework  /  Management  Platform]  Planning  and  Installation 
Guide  V3.0:  GC3 1-8382-00 

D.  Tivoli  [Framework  /  Management  Platform]  User’s  Guide;  V3.0GC31- 
8322-00 

E.  Tivoli  Framework  Services  Manual  V3.0:  GC31-8348-01 

F.  Tivoli  SNMP  Monitoring  Collection  Reference  V3.0:  SC31-8388-00 

G.  Tivoli  /  Enterprise  Console  Event  Adapter  Guide  /  SNMP;  SC3 1-8342-00 

H.  Tivoli  /  Enterprise  Console  Event  Adapter  Guide  /  HP  OpenView:  SC3 1- 
8338-00 

20.  System-wide  Design  Decisions 

This  section  summarizes  the  System  Requirements  document  and  indicates  how  these 
requirements  affect  the  system  architecture  design 

20. 1.  Management  Application  Integration 

The  system  shall  support  integrating  management  information  input  and  output  in  order  to 
coordinate  peer  management  systems.  Such  coordinated  management  is  delimited  by  four 
functions: 

1 .  monitoring  status  and  other  attributes 

2.  providing  historical  context  for  attribute  monitoring 

3.  monitoring  events 

4.  issuing  control  commands 

Integrating  two  network  management  systems  so  that  they  can  perform  such  functions  as 
peers  requires  transferring  each  of  the  four  categories  of  information  about  target 
components  to  and  from  the  management  systems  in  a  peer  to  peer  fashion.  Each  of  the 
four  functional  categories  of  information  transfer  is  implemented  as  one  or  more  jargons. 

20.2.  Target  Components  Integration 

The  network  management  functions  and  information  that  drive  the  distribution  and  security 
requirements  derive  from  standard  ATM  and  IP  components.  The  ATM  resources  will  be 
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controlled  according  to  XBind,  plus  relevant  standard  SNMP  MIB  definitions  available. 
The  IP  resources  also  will  be  managed  according  to  their  standard  SNMP  MIB  definitions 
as  made  available  by  the  network  management  systems.  To  the  extent  that  management 
APIs  are  defined  by  standard  MIBs,  transferring  such  information  between  management 
systems  is  relatively  straightforward,  but  to  the  extent  that  such  management  APIs  are 
implemented  in  system-specific  object  models,  transferring  information  between  such 
systems  may  require  significant  inter-system  communication  integration.  In  short  the 
application  layer  is  compatible,  but  the  underlying  distribution  infrastructure  is  not. 

20.3.  Object-Oriented  Architecture 

The  system  shall  support  object-based  datatypes  and  provide  object  methods  so  as  to 
support  access  to  management  information  from  a  wide  variety  of  network  components 
and  management  applications  without  having  to  explicitly  specify  each  individual 
interface. 

This  requirement  is  derived  from  the  need  to  integrate  peer-managed  target  managed 
objects  into  systems  whose  models  tend  to  be  hierarchical.  Object-oriented  systems’ 
object  instances  are  inherently  peers  —  most  of  the  hierarchical  primitives  are  either 
inheritance-based  or  containment-based.  Containment  relationships  are  defined  at  runtime 
and  as  such  are  open  to  being  used  to  support  configuration  of  peer-based  arrangements 
such  as  a  collection  of  jointly  managed  components. 

This  architecture  will  integrate  the  management  object  model  based  on  MIBs  with  the 
implementation  object  model  based  on  CORBA  by  defining  example  CORBA-based 
jargons  for  each  of  the  major  MIB  information  types. 

20.4.  Distribution 

20.4.1.  Distribution  Between  Peers 

The  first  distribution  requirement  is  that  the  systems  exchanging  management  data  do  so  as 
peers.  One  system  shall  not  be  dependent  on  the  other  to  operate  (although  it  may  not  have 
access  to  as  many  managed  objects).  However,  hierarchical  or  centralized  arrangements, 
while  not  the  target  configuration,  will  not  be  prevented. 

Because  the  peer  systems  will  have  their  own  collateral  services,  such  as  managed  object 
directory  services  and  local  clocks,  integration  and  distribution  of  information  from  such 
peer  collateral  services  is  also  necessary. 

20.4.2. WAN  Topology 

As  networks  expand,  they  are  increasingly  forced  to  interoperate  over  Wide  Area  Network 
(WAN)  interfaces  with  peer  networks  run  by  peer  organizations  using  their  own  network 
management  systems.  Support  for  WAN-based  distribution  across  such  borders  is  therefore 
required. 

Another  driving  force  for  WAN  distribution  is  the  nature  of  ATM  equipment  management 
interfaces  (support  for  which  is  another  Peer-to-Peer  system  requirement,  see  above).  A 
WAN  channel  is  often  the  initial  link  between  organizations  using  two  management 
systems  to  deploy  ATM  equipment,  much  like  a  lightweight  heaving  line  is  used  to  pull  a 
heavy  mooring  hawser  across. 
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The  primary  effect  on  the  system  architecture  was  ensuring  that  the  CORBA  ORB 
distribution  framework  properly  supports  WAN  distribution.  These  issues  are  covered 
below,  under  Coping  with  CORBA  Deficiencies. 

20.4.3. Distribution  of  Management  Control  and  Information 

The  management  information  distributed  shall  include  status  monitoring,  event  monitoring, 
issuing  control  commands  and  exchanging  historical  data  to  provide  context.  These  four 
functions  exemplify  both  the  major  application  functions  (monitoring  and  control)  and  the 
major  usage  patterns  (request/  response,  updating  large  datasets  or  infobases  and 
asynchronous  notification). 

The  functional  and  usage  characteristics  jointly  define  a  jargon,  an  inter-system  transfer 
mechanism  whose  characteristics  are  determined  by  the  information  and  its  usage.  For 
example,  management  application  features  such  as  historical  collections  should  be  fully 
accessible  from  a  number  of  different  management  systems.  Distribution  of  large  datasets 
of  potentially  processed  management  information  is  different  from  distributing  raw 
information  of  the  specific  devices. 

20.4.4.Standard  Distribution  Framework 

As  discussed  in  the  Requirements  Document,  we  consider  an  object-oriented  distribution 
standard  necessary  to  minimize  the  number  and  methods  of  low-level  mechanisms  used  for 
distribution.  Therefore,  we  have  chosen  the  Object  Management  Group’s  CORBA 
standard  as  providing  most  (although  not  all)  of  the  necessary  low-level  distribution 
capabilities  while  simultaneously  supporting  the  object-oriented  requirement.  The 
CORBA  standard  was  chosen  because  of  its  open  architecture  as  well  as  the  availability 
(and  maturity)  of  its  distributed  object  management  and  distribution  services.  It  was  also 
chosen  because  CORBA  ORBs  are  increasingly  seen  as  the  distribution  mechanism 
standard  of  choice  within  management  systems,  which  should  enhance  both  the  long-term 
extensibility  and  reduce  the  long-term  cost  of  management  systems. 

20.4.5.Coping  with  CORBA  deficiencies 

There  are  a  number  of  difficulties  in  using  CORBA  to  fulfill  all  the  requirements  discussed 
above: 

I.  Lack  of  CORBA  support  in  management  systems 

II.  Lack  of  CORBA  V2  HOP  support  in  management  system  ORBs 

III.  CORBA’s  reliance  on  LAN-centric  synchronous  RPC  for  transport 

IV.  CORBA’s  lack  of  full  and  sufficient  specifications  for  Collateral  Services: 

A.  Directory  Services  that  are  not  LAN-centric 

B.  Time  Services  that  are  not  implicitly  assumed  or  based  on  independent  local 
clocks 

C.  Security  Services 

D.  Management  Services  that  manage  the  CORBA  ORB  and  the  P2P  system 
extensions  without  depending  on  them  recursively. 
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E. 


Persistence  Services  that  go  beyond  writing  every  operation  to  disk  and 
which  are  customizable  on  a  per-object  basis 


Although  many  management  systems  are  object-oriented  as  far  as  the  managed  objects  are 
concerned,  the  implementation  of  the  system  itself  is  not  because  of  the  need  to  distribute 
management  information.  If  such  information  is  held  by  system  objects,  they  must  be 
distributed  and  standard  support  for  distributed  objects  is  a  recent  technological 
development.  Furthermore,  even  when  the  management  system  is  based  on  an  ORB,  inter¬ 
operation  with  that  ORB  may  be  difficult,  due  to  licensing  and  version  skew  problems. 

The  standardization  of  the  low-level  protocol  for  Internet  InterORB  Operability  has 
happened  only  recently,  and  its  usage  conventions  are  still  not  fully  worked  out  beyond  the 
demo  stage. 

This  architecture  intends  to  address  inter-system  communications  issues  by  selectively 
exporting  and  distributing  management  information,  and  providing  a  limited  number  of 
standardized,  CORBA-based  wrappers  for  non-CORBA-compliant  systems  (such  as  HP 
Openview)  where  direct  access  to  the  CORBA  ORB  framework  is  not  available.  When  an 
ORB  is  installed  but  its  framework  is  not  available,  the  use  of  an  auxiliary  ORB  and 
standard  CORBA  APIs  should  minimize  the  later  effort  of  porting  a  jargon  to  the 
previously  unavailable  embedded  ORB. 

The  underlying  transport  used  by  CORBA  for  procedural  language  mappings  like  C++,  C 
and  Java  Remote  Method  Invocation  (RMI)  is  Remote  Procedure  Call  (RPC).  This  is  a 
synchronous  blocking  mechanism,  which  we  find  inadequate  for  many  types  of 
management  information  usage,  especially  volatile  types  such  as  status  and  unpredictable 
ones  such  as  events.  Therefore,  this  architecture  will  address  standard  request/response 
usage  with  jargons  directly  defined  by  CORBA  IDL  members  and  attributes.  We  define 
non-request/response  usage  or  indirect  access  jargons  based  onBHS'S'  objects:  each  PASS 
object  is  a  CORBA-based  transport  object  typed  according  to  the  management  information 
it  carries.  PASS  objects  provide  an  experimental  asynchronous  notification  service 
implemented  using  an  equally  experimental  implementation  of  C++  templates  in  the  IDL 
compiler. 

Lack  of  a  well-specified  object  instance  directory  service  (or  Implementation  Repository) 
which  complements  the  existing  Interface  Repository  (type  and  other  meta-information) 
has  been  a  significant  drawback  of  the  CORBA  V2  standard  that  has  only  recently  been 
remedied.  The  standard  still  does  not  directly  address  the  WAN  distribution  requirement, 
and  CORBA  services  are  of  no  use  out  on  the  WAN  if  an  ORB  cannot  locate  them  when 
asked.  However,  it  does  specify  a  Directory  Service  interface,  which  can  be  integrated  with 
other  directory  services  whose  WAN  requirement  is  well  understood  and  supported.  This 
architecture  recommends  that  if  the  ORB’s  implementation  of  the  name  service  is 
inadequate,  the  system  should  supply  and  utilize  another. 

Lack  of  an  explicitly  specified  distributed  time  service,  which  allows  for  coordinated, 
accurate  timestamps  from  multiple  systems  (including  non-computer-based  clocks)  is  also 
a  significant  drawback.  Coordinated  time  is  not  a  critical  service  for  distributed  object 
brokering  per  se,  but  is  required  for  managing  distributed  processing  among  heterogeneous 
systems.  CORBA  implicitly  depends  on  one  of  the  two  most  widespread  time  services. 
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NTP  and  manual  synchronization.  Full  integration  of  CORBA  and  DCE  (which  has 
started  with  the  DCE  Name  Serviee)  would  also  remedy  this  laek  by  providing  the  DCE 
Time  Serviee. 

Eaek  of  a  fully  speeified  distributed  Seeurity  Serviee  is  being  addressed  by  the  Objeet 
Management  Group,  but  in  the  interim,  the  issues  must  be  addressed  loeally.  See  the  next 
section,  on  Security  Integration. 

Eaek  of  a  well-speeilied  distributed  management  arehiteeture  is  notieeable  mainly  in 
dealing  with  managing  ORBs  themselves,  particularly  when  the  management  serviees  are 
ORB-dependent  and  yet  must  funetion  before  the  ORB  is  fully  configured  and  functional. 
In  peer  arehiteeture,  with  potentially  many  ORBs,  this  is  partieularly  apparent.  These 
issues  are  being  addressed  loeally;  see  the  seetion  on  System  Management,  following. 

Eaek  of  a  persistenee  or  storage  interfaee  is  most  notieeable  in  the  laek  of  effieient 
implementations.  These  issues  are  being  addressed  loeally;  see  the  section  on  Storage,  just 
below. 

20.5.  Security  Integration 

Whenever  resource  eontrol  flows  are  distributed  aeross  a  network,  security  concerns 
beeome  more  prominent.  Sueh  seeurity  needs  to  eover  from  the  lowest  physieal  level  up 
through  the  applieation  level.  Eirst,  the  integrity  of  network  management  funetions  and 
information  needs  to  be  assured,  particularly  for  control  functions.  Second,  authorization 
and  access  eontrol  policies  should  be  supported,  ineluding  privaey  support  for  sensitive 
information.  Third,  minimal  proteetion  against  replay  attaeks  is  desirable,  although 
extending  it  to  a  eomprehensive  defense  against  denial  of  serviee  attaeks  is  not  eost- 
effeetive.  Einally,  derived  requirements  arising  from  the  need  to  extend  integrated  seeurity 
to  WAN  environments  via  eommon  security  mechanisms  such  as  firewalls  will  be 
eonsidered  Management  of  Seeurity  of  Management  eomponent  issues;  only  hooks  or 
plaeeholders  will  be  defined  or  provided.  This  arehiteeture  will  define  sueh  hooks  for  all 
relevant  seeurity  meehanisms  provided  by  the  two  ehosen  information  management 
systems,  plus  any  relevant  ones  speeified  by  Odyssey  Researeh  Assoeiates  in  their 
arehiteeture. 

20.6.  System  Management 

The  system  itself  will  provide  a  management  interfaee  and  GUI  that  will  enable  the  system 
integration  eomponents  to  be  installed  and  configured.  As  sueh  integration  eomponents 
will  themselves  be  jointly  managed  by  the  peer  systems,  reeursion  issues  will  be  dealt  with 
by  speeifying  low-level  or  minimal  subsets  for  eritieal  serviees. 

20.7.  Storage 

The  system  shall  support  usage-determined  storage  to  eomplement  the  distribution 
methods.  Just  as  the  usage  patterns  drive  the  ehoice  of  jargon,  they  will  also  drive 
deeisions  about  when  and  where  information  will  be  persistently  stored.  Persistenee 
meehanisms  will  either  eonform  to  the  CORBA  standard  or  their  usage  will  be  explieitly 
specified  as  a  distinet,  replaeeable  module  and  aecess  to  that  information  will  eonform  to 
MIB/CORBA  standards  via  a  jargon. 


51 


20.8.  Graphic  User  Interface 

The  system  GUI  shall  be  eompatible  with  the  HP  Openview  Xlib/Motif  GUI  and  Tivoli 
Systems  TME  at  the  X  Windows  level.  It  shall  also  allow  Motif-eompatible  HTML 
viewers  to  be  installed  on  the  systems,  sueh  that  displays  from  the  XBind  CGI  seripts  may 
be  displayed.  Additional  GUI  components  to  support  and  provide  access  to  integration 
components  will  be  defined  in  either  Tcl/tk  or  as  HTML  pages  suitable  for  viewing  via 
browsers. 

21.  Functional  Component  Description 

The  Functional  Component  Description  contains  a  lower,  but  still  functionally  oriented 
breakdown  of  the  major  components  of  the  system.  Items  in  this  section  are  described  in 
relation  to  how  they  provide  system  functionality  instead  of  how  they  function  as  discrete 
applications.  This  means  that  the  Graphical  User  Interface  (GUI)  would  be  described  in 
terms  of  the  operator  functionality  it  supports,  rather  than  the  method  it  would  use  to 
interface  with  network  devices. 

Integrating  two  peer  management  systems  requires  a  model  of  how  to  share  management 
tasks  in  a  peer-to-peer  fashion.  Management  Systems  are  applications,  which  hold  a  local 
view  of  one  or  more  managed  resources,  the  actual  instance  of  which  may  be  remote.  (See 
the  Management  System  diagram  below.)  The  management  view  of  a  managed  resource  is 
termed  a  managed  object  and  it  holds  a  number  of  items  of  information  about  itself, 
including  its  resource  type,  ID,  status,  relationships  with  other  managed  objects  etc.  (See 
Managed  Object  diagram  below).  Managed  Objects  are  defined  by  their  class  definitions, 
also  know  as  their  management  information  base  (MIB).  When  resources  are  remotely 
managed  across  the  network,  access  to  the  MIB  may  be  either  through  an  application/agent 
management  protocol  such  as  SNMP  or  by  distributing  the  Managed  Object  with  a 
distributed  object  infrastructure.  If  a  distributed  object  approach  is  used,  the  client  M.O.  is 
incorporated  into  the  management  system’s  application  and  the  server  M.O.  into  the 
managed  resource. 

Our  model  for  peer  sharing  of  such  managed  objects  is  intended  to  cover  1)  the  situation  in 
which  the  two  systems  have  ‘joint  custody’  of  some  managed  resource  or  2)  they  provide 
‘continuous  coverage’  as  a  parallel  load  sharing  arrangement  or  3)  they  have  a  sequential 
arrangement  in  which  there  is  a  changing  of  the  guard.  In  all  of  these  cases,  there  is  a 
period  in  which  parallel  management  or  ‘joint  custody’  is  desirable.  The  key  difference 
between  a  peer  management  system  architecture  and  a  hierarchical  one  is  based  on  the 
additional  requirements  generated  by  the  need  to  coordinate  decisions  in  a  joint  custody 
arrangement. 

To  support  joint  management  we  define  shared  managed  objects  .  A  shared  object  can  be 
any  of  the  managed  objects  definable  in  an  information  system  management  model.  The 
most  familiar  of  such  objects  are  the  real  network  components  or  devices  (as  in  an  SNMP- 
accessible  Managed  Object  Instance),  but  they  can  also  be  management-system-defined 
objects.  One  such  familiar  case  are  the  collections  of  management  information  intended  to 
be  transferable  between  network  management  systems,  such  as  an  event  log  or  a  historical 
statistical  dataset. 
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Figure  21-1  A  Management  System 


Figure  21-2  Managed  Object  Structure  and  Formal  MIB  Definition 

Managing  shared  objects  is  based  on  the  basic  management  functions,  monitoring  and 
control.  Making  such  standard  managed  objects  shared  involves  two  additional 
requirements: 

1 .  Distributing  monitoring  information  equally  to  all  responsible  peer  management 
systems 

2.  Synchronizing  control  responsibility 

Monitoring  and  controlling  a  shared  object  can  be  done  in  several  ways,  but  they  are  all 
based  on  designated  peer  management  systems  exporting  attribute  values  collected  locally 
to  a  distributed  shared  object  and  all  other  management  systems  then  monitoring  that 
shared  object.  The  simplest  form  of  monitoring  and  control  involves  using  a  simple 
CORBA  distributed  object  to  export  the  managed  object  from  a  designated  local  system 
(see  the  section  on  Basic  Management  of  Shared  Objects,  below).  All  the  other  peer 
systems  then  use  their  standard  monitoring  and  control  processes  to  monitor  and  control 
that  distributed  object.  This  approach  has  its  drawbacks  however,  involving  coordinating 
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control  of  monitoring  policy,  which  we  discuss  in  more  detail  below.  It  also  eannot  handle 
asynehronous  notifieation  easily,  foreing  event  monitoring  into  another  speeial  ease. 
However,  it  is  the  normal  approaeh  for  sharing  eontrol. 

The  Shared  Managed  Objeet  figure  below  shows  two  management  systems  sharing  sueh  an 
individual  managed  objeet,  Switeh,  whieh  the  management  system  on  the  left  is  exporting. 
In  addition  they  are  sharing  a  eolleetion  of  historieal  data,  an  example  of  an  alternate 
monitoring  approaeh. 


Figure  21-3  Shared  Managed  Objects 

This  alternate  approach  delegates  all  monitoring  responsibility  by  treating  the  managed 
objects  to  be  monitored  as  a  eolleetion.  Monitoring  is  the  most  eommon  ease  of  managed 
objeets  being  treated  eollectively,  beeause  both  daily  operations  and  statistieal  analysis 
require  on-going  monitoring  of  groups  of  managed  objeets.  In  those  eases,  making  the 
resulting  management  information  and  operations  shared  may  be  more  effieiently 
implemented  by  making  the  eolleetion  as  a  whole  shared. 

Transfer  of  colleetive  information  between  peer  systems  ean  then  be  optimized  if  necessary 
by  transferring  the  monitoring  polieies  (target  objects,  poll  interval,  optional  access 
eontrol,  ete.)  and  their  eontrol  to  the  loeal  management  system.  The  eolleeted  and  partially 
digested  monitoring  results  are  in  turn  transferred  from  that  eolleetor  management  system. 

This  delegation  approaeh  is  used  for  oolleeting  the  historieal  data  used  to  manage  trends. 
For  example,  sharing  historieal  statisties  would  involve  setting  up  shared  statistieal 
applieation  objeets  which  represent  the  historical  datasets  and  providing  an  administrative 
interfaee  that  would  eontrol  when  and  how  the  datasets  were  distributed. 


Managing  asynehronous  notifieations  or  events  from  shared  managed  objeets  is  often  also 
managed  via  this  delegation  approaeh.  The  shared  objeet  in  this  case  is  a  eolleetive  event 
souree  that  may  have  also  filtered  or  eombined  events  from  upstream  sourees  or  even 
generated  additional  events  based  on  ineoming  events. 


21. 1.  Basic  Management  of  Shared  Objects 


The  simplest  management  tasks  involve  low-level  monitoring  and  eontrol  operations  and 
basie  shared  management  is  based  on  a  direet  jargon  that  defines  MIB  aeeess  via  CORBA 


IDL. 


54 


Applying  a  GET  or  SET  to  a  shared  object’s  IDE-specified  attribute  is  simply  an  extension 
of  applying  them  to  a  regular  managed  object  and  involves: 

1 .  Initiating  the  command  from  within  the  first  NMS  or  from  its  GUI. 

2.  In  the  case  of  SET  operations,  verifying  control  access  is  permitted. 

3.  Requesting  the  information  from  or  operation  on  the  shared  object  via  the  jargon 
interface.  The  request  is  forwarded  to  the  responsible  peer  system  for  local  action  and 
the  result  awaited. 

4.  Invoking  the  translator  wrapper  for  reformatting  the  result  into  the  local  format  if 
needed. 

21.2.  Asynchronous  Attribute  Monitoring 

When  monitoring  a  shared  managed  object’s  attribute(s)  via  a  series  of  synchronous  polls 
or  GETs  consumes  too  many  resources,  an  alternative  shared  management  interface  can  be 
defined.  This  is  often  the  case  with  status  attributes,  which  are  either  so  stable  or  so 
volatile  as  to  be  barely  worth  GETting  even  if  only  one  management  system  is  involved, 
let  alone  one  or  more  peers.  In  any  case,  we  define  a  requirement  for  asynchronous 
monitoring  in  which  the  local  management  system  is  responsible  for  GETting  the  attribute 
value(s)  in  question  and  then  publishing  them  via  a  distributed  shared  object  for  peer 
systems  (including  possibly  itself)  to  monitor  by  subscribing  to  the  shared  object. 

21.3.  Shared  Historicai  Context  Data 

Sharing  data  such  as  trend  and  other  historical  information  is  a  combination  of  sharing 
standardized  management  data  and  non-standard  application  data  in  a  standardized  fashion. 
Sometimes  context  data  are  standardized  (such  as  MIB-defined  trend  data)  and  can  be 
embodied  in  a  peer  management  system  via  a  shared  standard  managed  object.  Other 
times,  this  is  not  so.  In  the  latter  case,  we  can  define  a  private  managed  object  class  that  is 
then  shared.  The  underlying  mechanisms  for  doing  this  are: 

1 .  Initiating  historical  data  collection  and  local  storage  from  the  component  sources  from 
within  the  transmitting  NMS  or  from  its  GUI. 

2.  Translating  or  reformatting  the  historical  data  if  needed. 

3.  Distributing  the  collected  data  via  a  jargon,  possibly  integrating  them  with  previously 
distributed  data  in  a  distributed  object  that  serves  as  the  basis  for  the  ‘shared  object’ 
view  in  each  participating  management  system. 

4.  Initiating  the  receiving  of  distributed  data  from  within  the  receiving  NMS  or  from  its 
GUI. 

5.  Translating  or  reformatting  the  historical  data  if  needed. 

21.4.  Shared  Object  Controi  Operations  Coordination 

As  mentioned  earlier,  the  second  of  the  two  major  distinguishing  features  of  peer 
management  architectures  is  coordination  of  control  operations.  Control  operations  are 
those  involving  writes,  either  as  actions  or  sets.  In  order  for  a  target  shared  managed 
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object  to  present  a  consistent  view  of  its  state  to  each  of  its  responsible  peer  managers, 
control  access  must  be  both  properly  authorized  and  sequenced.  Authorization  of 
operations  actually  consists  of  two  functions,  authentication  and  authorization.  In  sharing 
control  responsibility,  one  peer  management  system  delegates  authority  to,  and  defines  a 
trust  relationship  with,  another.  Such  a  trust  relationship  is  built  on  a  series  of 
authentication  and  authorization  handshakes  starting  with  the  human  operator  launching 
the  initial  management  application  GUI,  which  in  turn  initiates  programmatic  actions 
which  are  distributed  by  the  jargons,  which  in  turn  initiates  actions  by  the  receiving  peer 
system.  Occasionally,  the  relationship  is  extended  all  the  way  to  the  ultimate  target 
managed  object. 

The  initial  authentication  in  this  version  of  the  architecture  is  based  on  a  simple  user  ID 
and  password  mechanism  as  supplied  by  the  two  information  management  systems, 
OpenView  and  Tivoli.  Such  authentication  mechanisms  will  be  secure  only  to  the  extent 
that  their  vendors  have  provided  mechanisms.  Kerberos/DES  in  Tivoli  may  provide  some 
significant  protection,  for  example.  However,  both  OpenView  and  Tivoli’s  principals  are 
based  on  the  UNIX  login  IDs,  and  in  the  absence  of  Kerberos,  even  more  dependent  on  a 
secure  underlying  operating  system.  This  architecture  assumes  that,  when  necessary, 
secure  UNIX  kernel  and  inline  network  encryption  mechanisms,  such  as  FastTrack,  will  be 
added.  Authentication  following  the  initial  operator  validation  is  based  first  on  CORBA 
mechanisms,  followed  by  the  server  supplying  the  receiving  peer  system  with  an 
appropriate  user  identity. 

Authorization  in  this  version  of  the  architecture  is  based  on  a  simple,  platform-supplied 
scheme  in  which  per-object  access  control  sets  store  the  authorized  users'  IDs. 

Sequencing  of  control  requests  is  done  on  a  first  come,  first  served  basis  as  received  by  the 
object’s  server. 

21.5.  Collective  Event  Sources 

The  simplest  event  management  involves  defining  or  configuring  what  types  and  sources 
of  events  will  be  redirected  or  copied  to  the  peer  system.  The  underlying  mechanisms  for 
doing  this  are: 

1 .  Initiating  the  collection  from  the  component  sources  from  within  the  transmitting  NMS 
or  from  its  GUI. 

2.  Translating  the  event  data  if  needed. 

3.  Transferring  the  event  via  a  PASS  jargon  to  the  second  NMS. 

4.  Initiating  the  collective  source  and  monitoring  of  the  jargon  from  within  the  receiving 
NMS  or  from  its  GUI. 

5.  Invoking  the  translator  wrapper  for  reformatting,  if  needed. 

21.6.  Competing  Multiple  Sources 

There  is  one  case  in  which  collecting  management  information  from  multiple  sources  is 
undesirable:  when  the  sources  compete  with  each  other  to  supply  the  same  information 
about  the  same  shared  managed  object.  This  can  happen  when  the  information 
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management  system  both  eollects  its  own  information  and  imports  it  via  a  jargon  or  uses 
two  types  of  jargons  to  get  the  same  data.  There  are  two  approaehes  offered  to  deal  with 
this  situation;  overwrite  and  parallel  objeets.  In  the  overwrite  situation,  the  two  sourees  are 
merged  and  whiehever  one  writes  last  determines  the  eurrent  value.  This  approaeh  ean  be 
useful  for  objeets  whose  initial  or  eomplete  set  of  values  is  updated  via  one  synehronous 
souree  and  then  eritieal  values  are  updated  asynehronously,  or  when  switehing  from  one 
souree  to  the  other  with  some  overlap. 

The  other  approaeh  is  to  define  parallel  objeets  or  variant  attributes  on  the  platform,  with 
one  object  or  attribute  per  source.  This  is  useful  when  the  multiple  sources  are  truly 
competing  with  each  other  and  disagreements  on  the  value  need  to  be  recognized,  not 
overwritten. 

Generally  objects  (data  structures)  are  used  for  complex  information  that  must  be  read  or 
written  in  a  single  transaction  and  attributes  are  used  for  information  that  while  related  to 
the  other  fields  in  the  parent  object  can  be  read  and  written  independently.  The  definition  is 
done  within  the  information  management  system,  using  its  native  mechanisms.  For 
example,  in  HP  Openview  an  OV  Field  may  be  used  to  hold  an  attribute  value  imported 
from  a  jargon. 

22.  System  Interface  Description 

The  System  Interface  Description  describes  the  relationship  of  the  various  system 
component  types  described  in  the  System  Component  Description  section.  The  intent  of 
this  section  is  to  describe  how  the  system  components  interact  to  allow  the  functional 
components  to  support  the  functionality  described  in  the  Functional  Component  section. 

There  are  three  major  types  of  interactions  among  components.  First  are  the  configuration 
and  translation/formatting  interactions  between  management  system  components  and  the 
jargon  components.  Second  is  the  distribution  of  the  categorized-by-j argon  management 
information  between  the  client  and  server  parts  of  jargon  components.  Third  is  the 
management  of  the  jargons  that  make  an  object  shared.  The  following  sections  describe 
the  system  interfaces  that  allow  peer  management  system  components  to  utilize  jargon- 
distributed  information  and  how  such  translation  and  distribution  mechanisms  are 
configured. 

The  information  in  the  MIB  and  applications  has  a  range  of  distribution  requirements. 

Some  information  is  stable  and  is  required  to  persist  across  system  re-boots,  other 
information  is  extremely  volatile.  Some  information  comes  in  large  packages,  other 
information  is  compact  and  does  not  require  much  bandwidth  to  transmit.  Some 
information  transfers  are  initiated  by  the  management  system,  others  by  the  managed 
object. 

22. 1.  Jargon-based  Distribution 

The  interface  between  a  management  system  and  the  jargons  is  a  significant  portion  of  the 
system  architecture.  There  are  two  main  approaches,  the  direct  approach  that  utilizes 
CORBA  to  define  jargon  system  interfaces  directly  and  the  indirect  approach  used  when 
the  direct  approach  is  unavailable  or  inappropriate. 
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A  direct  interface  is  one  specified  in  IDL;  it  is  straightforward  and  is  covered  by  the 
CORBA  and  Corbus  documentation  referenced.  Often  such  managed  objects  are 
generated  by  MIB-to-IDL  compilers  such  as  SNMPIDL.  However,  the  easiest  way  to 
integrate  managed  objects  so  specified  in  a  management  system  is  to  provide  a  CORBA- 
compliant  ORB  framework  in  which  the  object  and  its  interface  can  reside.  Unfortunately, 
such  management  systems  are  rare  (although  becoming  less  so)  and  the  ones  that  exist  put 
a  premium  price  on  installing  the  managed  object  into  the  CORBA  ORB  framework. 

Even  if  access  to  a  CORBA  framework  is  available,  direct  interfaces  have  drawbacks  that 
make  them  inappropriate  for  distributing  some  types  of  management  information.  In 
particular,  the  heavy  reliance  of  CORBA  on  an  underlying  synchronous  and  quite  heavy 
RPC  transport  mechanism  makes  it  both  expensive  and  cumbersome  to  use  for  transient  or 
stream-like  information. 


However,  this  drawback  can  be  hidden  by  indirect  use  of  a  CORBA  based  PASS  object  to 
provide  a  distribution  channel  that  is  almost  as  efficient  as  an  asynchronous  message-based 
channel  while  it  is  as  correct  and  reliable  as  the  synchronous  channel  on  which  it  is  based. 
As  is  often  done  in  the  communications  world,  the  cost  of  the  underlying  synchronous 
channel  is  often  shared  by  a  number  of  multiplexed  asynchronous  users. 


Direct  Object 
Server 


I 


PASS  Object 
Server 


CORBA 

Interface 


Figure  22-1  Jargon-based  Shared  Managed  Objects 

Using  a  PASS  object  to  distribute  information  requires  additional  components  to  read, 
write  and  multiplex  to  the  channel,  these  actually  provide  the  API  for  the  peer  management 
systems.  Management  System-specific  translation  and  format  processing  can  be  integrated 
into  the  reader/writer  components,  as  can  distribution  policies  such  as  attribute  value  edge 
detection  or  delta  detection. 

For  example,  in  the  status  jargon  known  the  Management  Information  Status  Tracking 
(MIST),  whose  core  is  the  STATUS  PASS  CORBA  object,  the  server  process  implements 
the  policy  of  how  information  is  distributed  to  the  clients.  Once  a  subscriber  has  received 
a  complete  copy  of  all  the  elements  of  the  object,  only  new  or  different  elements  will  be 
sent.  Enforcing  this  restriction  is  not  placed  on  the  publishing  clients;  the  server  will 
determine  if  the  received  values  are  duplicates  of  what  it  has  already  stored. 

Jargons  based  on  PASS  objects  will  allow  external  clients  to  perform  the  following 
methods  on  the  application  meta-objects: 


1 .  Get  notified  of  new  object  values 
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2.  Get  sent  new  object  values  automatically 

3.  Define  new  objects 

4.  Define  new  object  values 

5.  Extract  particular  object  values 

6.  Delete  old  object  values 

The  ability  to  perform  these  MIST  functions  will  be  controlled  by  the  STATUS  PASS, 
PASSWRITER  and  PASSREADER  methods.  Eor  example,  the  current  STATUS 
PASSWRITER  interface  has  the  ability  to  publish  the  operational  status  of  a  set  of  managed 
objects  by  updating  the  STATE1S_PASS  object. 

The  reason  for  this  generic  PASS  object  approach  is  to  allow  datatype-  and  management 
system-specific  components  to  exist  independently  from  the  specifics  of  the  distribution 
and  subscription  mechanisms.  This  means  that  any  management  information  datatype  to 
be  distributed  can  be  mapped  onto  any  appropriate  distribution  method  without  affecting 
the  external  portions  of  the  jargon  definition. 

In  addition  to  the  fundamental  work  of  distributing  management  information  through 
various  kinds  of  jargons,  the  peer  management  systems  must  also  be  able  to  configure, 
monitor  and  otherwise  manage  these  extensions  that  permit  managed  objects  to  be  shared. 
Managing  jargons  and  other  meta-management  tasks  have  an  additional  constraint;  they 
must  pull  themselves  up  by  the  bootstraps  and  not  rely  on  jargon-based  mechanisms 
themselves  for  configuration  information  such  as  timestamps,  authentication,  existence  and 
location  information  unless  that  particular  collateral  services  sub-system  is  already  up. 

This  constraint  therefore  requires  that  a  startup  sequence  or  dependency  graph  be  specified 
for  each  site’s  configuration  in  which  the  source  of  the  meta-management  information  at 
each  stage  of  startup  and  shutdown  is  specified.  Such  graphs  may  be  used  only  by  manual 
configuration  systems  or  may  be  automated  such  that  the  SMO  Share  operation  (see  below, 
SMO  Operations)  control  flow  is  based  on  them. 

22. 1.1. Direct  IDL  Jargons 

Direct  IDE  Jargons  actually  have  two  functional  interfaces  defined  by  the  formal  IDE 
interface.  The  first  uses  a  combination  of  standard  Create,  Eist  and  Delete  on  a 
management  system-specific  factory  to  instantiate,  browse  and  remove  managed  objects 
shared  by  management  systems  of  one  type  with  management  systems  of  the  same  or 
another  type.  The  second  uses  the  CORBA  standard  Attribute  not  only  to  define  the 
datatypes  of  management  information  but  also  the  read  and  write  operations  —  the  GET 
and  SET  methods  —  in  IDE  terms.  This  is  the  IDL  often  generated  by  a  MIB-to-IDL 
compiler  tool.  Therefore  all  direct  IDL  jargons  have  the  form: 

interface  directSharedManagedObj  ect 

{ 

//  This  interface  IDL  is  often  generated  by  a  MIB  to  IDL  compiler,  then  included  in  the 
overall  IDL 
//  Datatypes 

//  These  are  SMO  class  specific 
//  Exceptions 


59 


//  These  are  SMO  elass  speeifie 

//  Operations 

//  Sinee  the  GET  and  SET  operations  are  implieit  in  the  attribute  speeifieation,  this 
seetion  is 

//  usually  empty 

//  Attributes 

//  Eist  all  shared  attributes  for  this  SMO  elass  here.  This  is  the  workhorse  seetion  of 
the  IDE 

attribute  MIBVarType  MIBVarName; 

}; 


interfaee  direetSharedManagedObjeetEaetory 

{ 

//  This  interfaee  may  have  to  be  hand-eoded  and  matehed  to  the  SMO  interfaee 
//  Exeeptions 

exeeption  SMO  invalidArg  {long  argTypeCode,  string  message}; 
exeeption  SMO  exNoSuehObj  {string  objStringRef}; 

//  Operations 

//  These  operations  are  faetory  standards 
//  ereate  Shared  Managed  Objeet 

SharedObjeet  Create(in  sharedObjArgl,  in  sharedObjArg2,...) 
raises  (  SMO  invalidArg,...)  ; 

//  destroy  Shared  Managed  Objeet 
void  Destroy}); 

//  list  Shared  Managed  Objeets 

sequenee<SharedObj eet>  EistAllObj eets(); 

//  Attributes 

//  Eaetory  attributes  tend  to  be  implementation  speeifie. 

}; 

22.1.2. PASS*based  Jargons 

The  PASS  is  a  eontainer  elass  that  serves  as  a  kind  of  intelligent  buffer  between  produeers 
(writers)  and  eonsumers  (readers)  for  any  user-supplied  type  of  data.  Multiple  writers  may 
populate  a  PASS  objeet,  and  the  data  they  provide  may  fan  out  to  multiple  readers.  Not  all 
data  supplied  by  writers  will  be  forwarded  to  readers;  the  details  of  the  fdtering  done  by 
PASS  are  deseribed  in  the  PASSREADER  and  PASS  WRITER  seetions  for  eaeh  PASS- 
based jargon. 

22.1.2. LPASS  IDLs 

I  I  Pile:  pass.idl 

//  Contents:  CORBA  IDE  speeifieation  for  Pass 
//  System:  P2P  development. 

//  Created:  14-Jan-1997 
//  Author: 

//  Remarks: 
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//  Generated  by  Idi  on  Tue  Jul  1 1  16:40:42  1995. 

//  $Header:  /nfs/morpheus/u3/p2p/rcs/doe/teehreports/sal-10.rtf,v  1.2  1997/10/16  21:05:08 
Ibob  Exp  $ 

//  COPYRIGHT  1997  BBN  Systems  and  Teehnologies 
//  A  division  of  Bolt,  Beranek  and  Newman,  Inc. 

//  All  Rights  Reserved. 

// 

// 10  Moulton  Street 
//  Cambridge,  Ma.  02138 
// 617-873-3000 

22.1.2.1.1. PASSREADER  IDL 

interface  PASSREADER 

{ 

void  DestroyO; 

//  Display  PASSREADER  object 
void  Display( 

out  string  pReaderName, 
out  unsigned  long  task, 
out  string  RegisteredOnPass 
); 

};  //  interface  PASSREADER 

22.1 .2.1 .2. PASSWRITER  IDL 

interface  PASSWRITER 

{ 

void  DestroyO; 

//  Display  PASSWRITER  object 
void  Display( 

out  string  pReaderName, 
out  string  RegisteredOnPass 
); 

};  //  interface  PASSWRITER 

22.1.2.1.3. PASS  IDL 

interface  PASS 

{ 

// 

//  Exceptions 

exception  PASSWRITER  INV  {}  ; 
const  string  PASSWRITER  INV  msg 

=  “PASSWRITER  object  invalid  or  does  not  exist.”; 
exception  PASSWRITER  MAX  SIZE  { 
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unsigned  short  MaxSize ; 

}; 

const  string  PASSWRITER  MAX  SIZE  msg 

=  “PASS  object  contains  maximum  number  of  PASSWRITERs.”; 
exception  PASSWRITER  NOT  REGISTERED  {}  ; 
const  string  PASSWRITER  NOT  REGISTERED  msg 

=  “PASSWRITER  has  not  been  added  to  this  PASS  object.”; 
exception  PASSWRITER  ALREADY  REGISTERED  {}  ; 
const  string  PASSWRITER  AEREADY  REGISTERED  msg 

=  “PASSWRITER  has  already  been  added  to  another  PASS  object.”; 
exception  PASSREADERJNV  {}  ; 
const  string  PASSREADER  INV  msg 

=  “PASSREADER  object  invalid  or  does  not  exist.”; 
exception  PASSREADER  MAX  SIZE  { 
unsigned  short  MaxSize ; 

}; 

const  string  PASSREADER_MAX_SIZE_msg 

=  “PASS  object  contains  maximum  number  of  PASSREADERs.”; 
exception  PASSREADER  NOT  REGISTERED  {}  ; 
const  string  PASSREADER  NOT  REGISTERED  msg 

=  “PASSREADER  has  not  been  added  to  this  PASS  object.”; 
exception  PASSREADER  ALREADY  REGISTERED  {}  ; 
const  string  PASSREADER  ALREADY  REGISTERED  msg 

=  “PASSREADER  has  already  been  added  to  another  PASS  object.”; 
exception  PASSREADER_BUSY  {}  ; 
const  string  PASSREADER  BElSY  msg 

=  “PASSREADER  is  already  blocked  waiting  for  a  PAYEOAD.”; 
exception  PAYED AD  INV  {}  ; 
const  string  PAYEOAD_INV_msg 

=  “PAYEOAD  object  invalid  or  does  not  exist.”; 
exception  PAYEOAD  MAX  SIZE  { 
unsigned  short  MaxSize ; 

}; 

const  string  PAYEOAD  MAX  SIZE  msg 

=  “PASS  object  contains  maximum  number  of  entries.”; 


// 

//  PASS  Operations 

// 

//  Unconditionally  destroy  PASS  object 
void  DestroyO; 

//  “Display”  a  PASS  object.  This  returns  information  that  is 
//  useful  for  sanity  checking/debugging.  This  operation  does  not 
//  change  the  state  of  the  object. 
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void  Display( 

out  string  pPassName, 
out  string  pPassType, 


//  name  of  this  PASS 
//  type  of  this  PASS 


//  #  of  tasks 

// 

//  #  of  writers  that  ean  register 
//  #  of  readers  that  ean  register 


out  unsigned  short  pMaxTasks, 
out  unsigned  short  pMaxRees, 
out  unsigned  short  pMaxWriters, 
out  unsigned  short  pMaxReaders, 
out  unsigned  short  pReeCount,  // 

out  sequenoe<PASSWRITER>  pWriterList,  //  list  of  eurrent  writers 
out  sequenoe<PASSREADER>  pReaderEist  //  list  of  eurrent  readers 
); 


//  Add  a  new  PASSWRITER  to  a  PASS  objeet  by  name 

PASSWRITER  AddWriter(in  PASSWRITER  Writer, 
in  string  WriterName) 
raises(PASSWRITER_MAX_SIZE); 

//  Remove  a  PASSWRITER  from  a  PASS  objeet 

void  RemoveWriter(in  PASSWRITER  Writer) 
raises(PASSWRITER_INV); 

//  Add  a  new  PASSREADER  to  a  PASS  objeet  by  name 

PASSREADER  AddReader(in  PASSREADER  Reader, 

in  string  ReaderName) 
raises(PASSREADER_MAX_SIZE); 

//  Remove  a  PASSREADER  from  a  PASS  objeet 

void  RemoveReader(in  PASSREADER  Reader) 
raises(PASSREADER_INV); 

}  ;  //  interfaee  PASS 


22.1.2.1.4.PASSMGR  IDL 

in  file  pass.idl: 

interfaee  PASSMGR 

{ 


//  Exeeptions 


exeeption  PASS  EXISTS  {}  ; 
eonst  string  PASS  EXISTS  msg 

=  “PASS  objeet  already  exists.”; 
exeeption  PAS  S_INV  {}  ; 
eonst  string  PASS_INV_msg 

=  “PASS  objeet  invalid  or  does  not  exist.”; 
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exception  PASS_TYPE_INV  {}  ; 
const  string  PASS  TYPE  INV  msg 
=  “PASS  type  invalid.”; 


// 

//  Operations 

// 

//  Create  a  PASS  object 

PASS  Create(in  string  PassName, 
in  string  PassType, 
in  unsigned  short  MaxRecs, 
in  unsigned  short  MaxWriters, 
in  unsigned  short  MaxReaders) 
raises(PASS_EXISTS,  PASSJNV); 

//  Eookup  a  PASS  object  given  its  name  and  type. 

PASS  Eookup(in  string  PassName,  in  string  PassType) 
raises(PASS_INV); 

//  PassEntry  contains  the  name  and  type  of  a  PASS  object. 

//  It  is  used  in  the  parameter  list  of  the  Eist  operation, 
struct  PassEntry  { 
string  name; 
string  type; 


//  Eist  returns  the  names  and  types  of  all  PASS  objects 
//  known  to  this  PASSMGR. 
void  Eist  ( 

out  sequence<PassEntry>  pPassEist 

); 

};  //  interface  PASSMGR 

//  local  types  start  here. 

//  do  an  #include  “type.idl”  to  pull  them  in 
//  They  in  turn  will  pull  in  the  PASS  Template  IDE 


22.1 .2.1 .5.PASS  Template  IDL 

interface  PAYEOAD 

{ 

PAYEOADSTRUCT 

void  Display(out  PAYEOAD  REP  ppRec); 

void  DestroyO; 

}; 
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interface  PAYLOAD  PASS  :  PASS  { 

PAYLOADSTRUCT 

//  Add/update  PAYLOAD  to  a  PASS  Status  object 

void  AddUpdateRec(in  PASSWRITER  Writer,  in  PAYLOAD  REP  pRec) 
raises(PAYLOAD_INV,  PAYLOAD  MAX  SIZE); 

//  Remove  an  existing  PAYLOAD  from  a  PASS  object 
void  RemoveRec(in  PAYLOAD  REP  ppRec) 
raises(PAYLOAD_INV); 

//  Eookup  a  PAYLOAD  in  a  PASS  object 

void  LookupRec(inout  PAYLOAD  REP  ppRec) 
raises(PAYLOAD_INV); 

//  Eookup  next  PAYLOAD  object 

void  LookupNextRec(in  PASSREADER  Reader,  out  PAYLOAD  REP  ppRec) 
raises(PAYLOAD_INV); 

}; 

#undef  PAYLOAD 
#undef  PAYLOADSTRUCT 
#undef  PAYLOADREP 
#undef  PAYLOADPASS 

22.1. 2.2.0bject Interactions  in  PASS 

The  following  diagram  shows  a  typical  pattern  of  messages  and  object  creation  that  might 
be  seen  in  a  system  using  PASS  objects  to  transfer  Status.  The  commentary  explains  the 
objects  involved,  the  effects  of  the  messages,  and  what  is  going  on  behind  the  scenes. 

Writer  Client  PASSMGR  STATUS  PASS  Reader  Client  PASSREADER  PASSWRITER 


Figure  22-2  Example  PASS  Jargon  Usage 


65 


1 .  The  writer  loeates  a  preexisting  PASSMGR  objeet,  either  by  retrieving  its  objeet 
referenee  from  the  PASSMGR  OBJECT  environment  variable  or  via  the  Corbus 
funetion  bind_to_any_in_elust(),  and  sends  it  a  ereate  message  speeifying  it  needs  a 
PASS  object  through  which  STATUS  objects  can  be  passed. 

2.  The  PASSMGR  object  is  a  factory  and  lookup  service  for  PASS  objects.  Here  it  fulfills 
its  factory  duty  by  creating  a  STATUS  PASS  object  in  response  to  the  Create  request 
in  (1).  Note  that  pure  PASS  objects  are  never  created;  only  subclasses  of  PASS  that  are 
specialized  to  carry  a  particular  data  type  can  be  created.  In  C++  parlance,  PASS  is  an 
abstract  base  class. 

3.  PASSMGR  returns  the  object  reference  of  the  created  STATUS_PASS  object,  pO. 

4.  Before  the  writer  client  can  begin  pumping  data  into  the  STATUS  PASS  object  pO,  it 
must  register  itself  as  a  writer  by  invoking  the  AddWriter  operation  on  pO. 

5.  In  response  to  the  AddWriter,  pO  creates  the  PASSWRITER  object  and  returns  its 
object  reference,  wO,  in  step  (6).  Alternatively,  the  writer  could  have  passed  in  a 
previously  created  PASSWRITER  object.  Internally,  pO  remembers  that  wO  is  now 
registered  for  writing  on  pO. 

6.  The  writer  now  presents  the  first  piece  of  data,  statusl,  to  pO  with  the  AddUpdateRec 
operation.  The  writer  identifies  itself  to  pO  by  supplying  the  PASSWRITER  object  wO 
from  step  (6).  Currently,  PASS  objects  make  little  use  of  the  writer  identity,  but  it 
could  be  used  in  the  future  to  implement  various  policies,  e.g.,  prioritization  of  the  data 
to  be  distributed  to  readers  based  on  who  wrote  it. 

7.  Attention  now  shifts  to  the  reader  side.  A  reader  client  wants  to  receive  data  from  a 
PASS  object  named  “pO”.  It  finds  a  PASSMGR  object  using  methods  similar  to  those 
described  in  step  (1),  and  invokes  the  EookupByName  operation  on  the  PASSMGR 
object,  which  returns  the  object  reference  pO  in  step  (9).  PASSMGR  objects  also 
support  an  operation  that  lists  all  available  PASS  objects  by  name.  These  operations 
comprise  the  “lookup  service”  mentioned  above. 

8.  Exactly  paralleling  the  writer  registration  process,  the  reader  client  does  an  AddReader 
on  pO,  and  pO  creates  the  PASSREADER  rO  (11)  and  returns  it  (12). 

9.  The  reader  client  asks  for  the  first  piece  of  data  from  pO,  and  pO  returns  statusl  (14) 
that  was  written  in  step  (7). 

10.  The  reader  client  asks  for  the  next  piece  of  data  from  pO,  but  since  there  is  none,  it  does 
not  immediately  receive  a  reply.  Internally,  pO  suspends  the  thread  that  is  servicing  this 
operation. 

11.  The  writer  sends  another  piece  of  status  information,  status2. 

12.  pO  awakens  the  thread  suspended  in  (15)  so  that  it  can  return  status2  to  the  reader. 

22. 1.3. Jargon  Management  and  Shared  Managed  Objects 

To  manage  a  Shared  Managed  Object  consists  primarily  of  identifying  which  underlying 

Managed  Objects  will  be  shared,  with  whom  they  will  be  shared  and  enumerating  the  data 

and  operations  that  will  be  shared  using  jargons.  To  do  this  we  define  the  following  six 

classes: 
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1.  Peer  Manager  Set:  a  set  of  one  or  more  Peer  Managers,  comprising  the  known, 
permitted  and  available  peer  managers.  There  are  at  least  two  instances  of  this  class, 
one  of  all  possible  managers,  known  as  the  Peer  Manager  Registry,  the  other 
associated  with  the  formal  SMO  definition,  known  as  the  CustodianList.  Offers  the 
normal  set-type  operations  such  as  add,  remove  and  browse. 

2.  Peer  Manager:  a  managed  object  representing  a  remote  management  system.  It  is 
defined  by  the  Peer  Manager  Attributes,  below,  and  offers  the  normal  object  operations 
of  Create,  Destroy  and  Display. 

3.  Shared  Managed  Object  Set:  a  set  of  zero  or  more  SMOs  comprising  the  managed 
objects  shared  by  this  management  system  with  the  remote  Peer  Manager.  Called 
SMOList  in  the  jargon  definition  sections  below.  Offers  the  normal  set-type  operations 
such  as  add,  remove  and  browse. 

4.  Shared  Managed  Object:  a  managed  object  whose  information  is  imported  or  exported 
for  sharing.  It  is  defined  as  a  collection  of  jargons  connecting  a  local  managed  object 
with  the  remote  peer  managers  in  the  Custodial  Peer  Manager  Set. 

5.  Jargon  Set:  a  set  of  one  or  more  Jargons  comprising  the  exported  and  imported 
information  belonging  to  a  local  managed  object.  The  normal  set-type  operations  of 
add  and  remove  are  subsumed  by  the  SMO  operations  share  and  unshare.  Called 
localJargonList  in  the  formal  SMO  definitions  below. 

6.  Jargon:  a  mechanism  for  importing  or  exporting  a  particular  type  or  class  of 
management  information.  There  are  two  families  of  jargons,  direct  or  synchronous 
request/response  based  and  indirect  or  Piecewise  Asynchronous  Service  (PASS)  based. 

22.1. 3.1. Peer  Manager  Attributes 

1 .  remPeerSysName:  The  host,  system  or  node  name  of  the  remote  peer  management 
system;  a  human  readable  string  that  can  be  mapped  into  the  network  address  used  by 
management  by  a  directory  service.  In  this  version  of  the  architecture,  a  DNS  name. 

2.  remPeerlPAddr:  The  network  address  used  of  the  remote  peer  system,  used  when  the 
directory  service  is  not  available  or  accurate.  In  this  version  of  the  architecture,  an  IP 
v6  address. 

3.  remPOC:  The  Point  of  Contact  information  for  manual  administration  coordination, 
this  attribute  set  includes  the  person’s  name,  organization,  address  type  (email,  phone, 
postal,  etc.)  and  address. 

4.  remPlatformType:  The  type  name  of  the  remote  peer  management  platform.  In  this 
version  of  the  architecture,  an  enumeration,  in  this  version  of  the  architecture,  of 
HPOV  or  TME,  for  HP  OpenView  and  Tivoli  TME  respectively. 

22.1.3.2.Shared  Managed  Object  Attributes 

localMOID:  The  Managed  Object  ID;  the  name  or  stringified  object  identifier  of  the  local 

managed  object  to  be  shared.  Used  as  entry  in  the  SMOEist.  Must  include  the  sysName 

and  any  subsystem  identification  necessary  to  fully  distinguish  the  managed  resource  for 

the  local  information  management  system. 
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localJargonList:  A  list  of  the  supported  jargons,  speeified  as  a  sequenee  of  items  from  the 
jargon  enumeration.  In  this  version  of  the  arehiteeture,  the  jargon  enumeration  eonsists  of 
Status,  Trend  Bulk,  Trend  Subseription,  Snapshot,  Control  and  Event.  Seleeted  jargons  are 
aetivated  by  the  Share  operation. 

localShareType:  The  direetion  of  the  jargon  information  and  eontrol  flow;  whether  the 
loeal  management  system  is  exporting  or  importing  the  managed  objeet  information. 

CustodianList:  the  set  of  names  or  stringified  objeet  identifiers  of  the  remote  Peer 
Managers  whieh  share  the  management  responsibility  for  this  SMO. 

22.1.3.3.SMO  Operations 

Share  extends  a  Managed  Object  or  Collection  by  setting  the  SMO  extension  attributes, 
creates  a  SMOList  entry  and  starts  any  jargons  specified,  including  any  necessary 
wrappers. 

Unshare  stops  the  wrappers  (which  may  also  discontinue  the  jargon  server)  and  removes 
the  SMOList  entry  and  SMO  attributes. 

Browse  lists  all  the  shared  managed  objects  currently  exported  by  the  jargon(s)  between 
platforms  of  the  local  type  and  those  of  the  remote  type. 

22.2.  Asynchronous  Attribute  Monitoring  interface 

The  most  critical  of  the  attributes  that  require  asynchronous  monitoring  are  status 
attributes.  For  this  reason,  the  first  asynchronous  attribute  jargon  will  distribute  status 
information.  Status  information  about  IP  managed  objects  can  be  determined  either  by 
polling  SNMP  agents  for  status  information  (such  as  Uptime)  or  by  querying  the  standard 
status  interfaces  on  the  information  management  system  (such  as  the  OpenView  managed 
node  status  attribute).  This  information  then  will  be  forwarded  to  a  PASS-based  status 
jargon  known  as  the  STATUS_PASS  to  be  distributed  to  the  peer  systems.  Each 
STATUS  PASS  holds  information  about  a  single  managed  object  in  a  status  record 
datatype  used  by  the  template  process  to  refine  the  PASS  into  a  STATUS  PASS. 

The  resulting  STATUS_PASS  records  contain: 

1 .  Network  Address 

2.  Operational  Status 

3.  HeartBeat  information 

The  Network  Address  attribute  is  an  address  used  to  identify  a  single  interface  on  a 
managed  system.  In  the  case  of  a  network  host,  this  may  be  the  only  interface  and  devices 
like  routers  or  switches  can  support  multiple  interfaces. 

The  Operational  Status  attribute  holds  a  single  value  whose  type  is  determined  by  the 
status  translation  tables  for  the  peer  management  systems  in  question,  but  which  most 
often  is  derived  from  the  enumeration  defined  for  Status  by  the  management  platform  or 
occasionally  by  the  MIB. 

The  HeartBeat  attribute  is  a  jargon  management  field.  It  is  discussed  in  the  management 
services  section. 


68 


Once  a  management  system  has  subseribed  to  status  information,  it  will  eontinue  to  reeeive 
status  items  (as  STATUS _P ASS  records  until  the  subseription  eonneetion  is  terminated. 

Supplying  status  from  non-SNMP  sourees  will  require  a  suitable  Status  PASSWRITER 
funetion  whieh  ean  take  in  status  from  the  non-SNMP  souree  on  a  speeified  regular  basis 
and  provide  a  standard  translation  if  neeessary.  It  will  also  require  a  suitable  Status 
PASSREADER  funetion  whieh  will  provide  a  library  of  the  inverse  read  funetions. 

22.2.1. Status_PASS  API 

The  Status  PASS  API  eonsists  of  two  operations  and  a  distribution  or  update  policy.  The 
operations  include  a  read  operation,  whieh  posts  a  read  request  via  the  PASSREADER 
library,  and  a  write  operation,  whieh  writes  via  the  PASSWRITER.  Distribution  poliey  for 
status  information  is  only  to  write  a  new  status  record  if  the  ineoming  status  value  is  new 
or  different .  Status  information  only  is  given  to  readers  if  they  are  newly  ereated  (and 
henee  have  not  seen  any  of  the  data  yet)  or  if  the  reader  is  already  up  but  there  is  a  newly 
written  status  value.  Furthermore,  the  status  data  may  be  deelared  persistent;  if  the  server 
erashes  and  restarts,  subsequently  registered  PASSReader  will  get  all  of  the  eurrent  data 
(per  the  previous  rule). 

22.2.2.Status  PASSREADER 

The  status  PASSREADER  is  a  library  objeet  that  embodies  the  read  distribution  poliey  for 
Status  information. 

22.2.3.Status  PASSWRITER 

The  status  PASSWRITER  is  also  a  library  objeet  that  embodies  the  write  distribution 
policy  for  Status  information. 

22.2.4.STATUS_PASS  IDEs 

Using  the  standard  CORBA  IDE  meehanism,  #inelude  “status. idl”,  add  the  following 

status  refinements  as  stored  in  the  file  status. idl 

#defme  PAYEOAD  STRUCT 

struet  STATUS  REP  { 

string  ReeName; 

string  Rec  Value; 

string  Hearts  eat; 

}; 


#defme  PAYEOAD_REP  STATUS_REP 

#defme  PAYED  AD  STATUS 

#defme  PAYEOAD  PASS  STATUS  PASS 

//  The  following  pass-template  IDE  is  deseribed  in  the  seetion  Pass  Template  IDE 
#inelude  “pass-tmpl.idl” 

22.3.  Historical  Data  Collection  and  Distribution 

The  source  of  all  trend  and  other  historieal  context  data  is  a  periodie  colleetor  of  some 
standard  attribute  values  for  one  or  more  attributes.  Making  those  historieal  datasets 
available  to  a  peer  manager  ean  take  several  forms. 
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The  basic  model  of  stable  historical  dataset  transfer  populates  its  Trend  distributed  object 
on  Create  or  Read.  The  server  takes  a  snapshot  of  (for  example)  the  HP  Openview 
historical  database  files,  converts  them  to  the  IDL-defined  wire  format  and  ships  them  back 
to  the  client. 

It  is  also  possible  to  declare  the  Trend  object  persistent  and  use  a  storage/retrieval- 
optimized  persistence  API  to  keep  a  stable  copy  within  the  distributed  system. 

When  the  historical  dataset  is  volatile,  for  example  when  it  is  still  in  the  process  of  being 
created  at  the  source  peer  management  system  but  the  other  systems  wish  immediate 
access,  another  Trend  jargon  is  necessary,  the  Trend  Subscription  jargon.  All  of  the  Trend 
variants  of  historical  context  transfer  include  implementations  of  the  following  interface 
methods.  Note,  Items  c)  through  e)  may  be  bundled  into  a  single  fully  distinguished 
identifier  such  as  an  OID. 

1 .  An  operation  to  read  a  chunk  of  history  from  the  Trend  object.  Input  arguments 
include; 

a)  the  time  collection  started  (the  anchor  time) 

b)  the  time  interval  covered 

c)  the  source  managed  system 

d)  the  source  managed  component  class  ID  on  that  node  (if  any) 

e)  the  source  component  instance  ID  on  that  node  (if  any) 

f)  the  MIB  variable  ID 

g)  the  MIB  variable  value 

h)  resampling  interval  required  Resampling  allows  the  data  to  be  treated  as  if 
collected  at  regular  intervals  even  if  they  were  not.  A  zero  value  means  no 
resampling 

It  will  return  a  sequence  of  structures  or  objects  that  contain: 

a)  the  time  collection  started  (the  anchor  time) 

b)  the  time  interval  covered 

c)  the  source  managed  system 

d)  the  source  managed  component  class  ID  on  that  node  (if  any) 

e)  the  source  component  instance  ID  on  that  node  (if  any) 

f)  the  MIB  variable  ID 

g)  the  MIB  variable  value 

2.  An  operation  to  write  a  chunk  of  history  to,  or  create,  the  Trend  object  using  the 
same  format  as  the  read  for  input  arguments.  In  some  Trend  jargons  this  operations 
will  be  implicit  in  either  the  Create  or  Read  operation,  in  which  case  the  Trend 
server  must  be  collocated  with  the  source  of  the  Trend  data. 

3.  An  operation  to  list/browse  the  available  Trend  data.  The  user  will  be  able  to  get  a 
list  of  Trend  data,  discover  what  hosts  and  SNMP  variables  are  recorded  in  them, 
and  for  what  time  periods. 

4.  An  operation  to  browse  the  available  Trend  objects  that  hold  already  fetched  Trend 
data. 
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The  ‘chunks’  of  history  or  TrendTables  are  optimized  for  transfer  by  casting  them  into  one 
of  three  forms; 

1 .  by  time 

2.  by  variable 

3.  by  device 

In  all  cases,  the  data  is  a  sequence  of  samples,  and  one  sample  is  characterized  by  the  5- 
tuple  (start  time,  end  time,  device,  variable,  value)  However,  sending  all  five  fields  for 
every  sample  would  be  wasteful,  since  there  will  usually  be  much  redundancy.  For 
example,  there  will  probably  only  be  a  few  devices  and  variables  in  a  table  compared  to  the 
total  number  of  samples.  So,  we  define  three  different  table  formats  to  factor  out  different 
pieces  of  the  redundant  information.  This  crude  form  of  compression  is  useful  since  the 
trend  data  can  be  very  large  (megabytes).  It  is  up  to  the  client  to  decide  which  format  to 
use. 

22.3.1. TrendTable  by  Time 

A  trend  table  that  is  organized  by  time  will  factor  out  the  start  time  from  the  5 -tuple,  so  the 
returned  data  will  be  a  sequence  of: 

1 .  start  time 

2.  sequence  of  (end  time,  device,  variable,  value) 

This  means  that  all  the  samples  that  were  taken  at  the  same  time  appear  together. 

22.3.2. TrendTable  by  Device 

A  trend  table  that  is  organized  by  device  will  factor  out  the  device  from  the  5 -tuple,  so  the 
returned  data  will  be  a  sequence  of: 

1 .  device 

2.  sequence  of  (start  time,  end  time,  variable,  value) 

This  means  that  all  the  samples  that  were  taken  for  the  same  device  appear  together. 

22.3.3.  TrendTable  by  Variable 

A  trend  table  that  is  organized  by  variable  will  factor  out  the  variable  from  the  5 -tuple,  so 
the  returned  data  will  be  a  sequence  of: 

1 .  variable 

2.  sequence  of  (start  time,  end  time,  device,  value) 

This  means  that  all  the  samples  that  were  taken  for  the  same  variable  appear  together. 
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22.3.4.Common  Trend  Datatypes  IDL 


//  File:  nmtypes.idl 

//  Contents:  idl  include  for  common  types  used  in  network  management 
//  System:  p2p  development. 

//  Created:  15-Jul-1997 
//  Author:  David  P.  Wiggins 

//  Remarks:  this  file  is  intended  to  be  included  by  other  idl  files 

//  $Header:  /nfs/morpheus/u3/p2p/rcs/doc/techreports/sal-10.rtf,v  1.2  1997/10/16  21:05:08 
Ibob  Exp  $ 

//  COPYRIGHT  1997  BBN  Systems  and  Technologies 

//  10  Moulton  Street  Cambridge,  Ma.  02138  617-873-3000 

//  Identifier  for  a  device  —  just  an  IP  address, 
typedef  sequence<octet>  DevicelD; 

//  Time  in  seconds  since  Jan  1  1970. 
typedef  unsigned  long  TimeStamp; 

//  Difference  between  two  TimeStamps  in  seconds, 
typedef  unsigned  long  TimeCovered; 

//  Part  or  all  of  the  MIB  object  ID  (OID). 
typedef  sequence<unsigned  long>  MIB  Variable; 

//  MIB  Variable's  value.  Assume  everything  can  be  represented  by  a  double, 
typedef  double  MIBValue; 


22.3.5.Trend  Bulk  IDL 

//  File:  trend.idl 

//  Contents:  trend  bulk  jargon  interface 
//  System:  p2p  development. 

//  Created:  17-July-1997 
//  Author:  David  P.  Wiggins 

//  SHeader:  /nfs/morpheus/u3/p2p/rcs/doc/techreports/sal-10.rtf,v  1.2  1997/10/16  21:05:08 
Ibob  Exp  $ 

//  COPYRIGHT  1997  BBN  Systems  and  Technologies 

//  10  Moulton  Street  Cambridge,  Ma.  02138  617-873-3000 
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#include  "nmtypes.idr 


struct  DeviceVariable  { 

DevicelD  device;  //  IP  addr 
MIB Variable  variable;  //  SNMP  OID 
}; 


typedef  sequenee<DevieeVariable>  seqDevieeVariable; 


enum  Trend! ableXype  { 
Trend!  ableByT  ime, 
Trend!  ableBy  V  ariable, 
TrendTableByDeviee 

}; 


//  Parent  elass  of  all  trend  tables, 
interfaee  TRENDTABLE  { 

//  Display:  return  information  about  this  trend  table. 

//  Added  for  debugging;  it  should  either  be  removed  or  elaborated 
//  to  also  return  the  deviees  and  variables  in  the  trend  table, 
void  Display( 

out  TimeStamp  startTime, 

out  TimeStamp  end! ime 

); 


//  Destroy:  delete  this  trend  table 
void  DestroyO; 

}; 


//  table  organized  primarily  around  the  sample  time 
interfaee  TRENDTABLE  BYTIME  :  TRENDTABLE  { 

//  info  returned  for  eaeh  time  value 
struet  DevieeVariableValue  { 

DevieelD  deviee; 

MIBVariable  variable; 

MIB  Value  value; 

TimeCovered  timeSpan; 

}; 


struet  Time_DevieeVariableValue  { 

TimeStamp  anehorTime; 
sequenee<DevieeV ariableV alue>  dvv; 
}; 
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//  GetTable;  return  trend  data  for  given  the  deviee/variable 
//  pairs  that  falls  within  the  starting  and  ending  time  period. 
sequence<T ime  DeviceV ariableV alue>  GetT able( 
in  seqDevieeVariable  sdv, 
in  TimeStamp  startTime, 
in  TimeStamp  endTime 
); 

}; 


//  table  organized  primarily  around  the  variables 

interface  TRENDTABLE  BYVARIABLE  :  TRENDTABEE  { 

//  info  returned  for  each  variable 
struct  DeviceTimeValue  { 

DevicelD  device; 

TimeStamp  anchorTime; 

MIB  Value  value; 

TimeCovered  timeSpan; 

}; 


struct  Variable  DeviceTimeValue  { 

MIB  Variable  variable; 
sequence<DeviceTimeValue>  dtv; 
}; 


//  GetTable:  return  trend  data  for  given  the  device/variable 
//  pairs  that  falls  within  the  starting  and  ending  time  period. 
sequence<V ariablc  DeviceTimeV alue>  GetT able( 
in  seqDevieeVariable  sdv, 
in  TimeStamp  startTime, 
in  TimeStamp  endTime 
); 


//  table  organized  primarily  around  the  devices 
interface  TRENDTABLE  BYDEVICE  :  TRENDTABEE  { 

//  info  returned  for  each  device 
struct  VariableTime Value  { 

MIBVariable  variable; 

TimeStamp  anchorTime; 

MIB  Value  value; 

TimeCovered  timeSpan; 

}; 
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struct  Device  VariableTimeValue  { 

DevicelD  device; 

sequence<VariableTimeValue>  vtv; 

}; 


//  GetTable:  return  trend  data  for  given  the  device/variable 
//  pairs  that  falls  within  the  starting  and  ending  time  period. 
sequence<Device_V ariableT imeV alue>  GetT able( 
in  seqDevieeVariable  sdv, 
in  TimeStamp  startTime, 
in  TimeStamp  endTime 
); 

}; 


22.3.6.Trend  Bulk  Factory  IDL 

From  the  file  trend.idl; 

interface  TRENDFACTORY 

{ 

//  Added  these  to  get  around  Corbus  limitations. 
typedefMIB Variable  TFMIB Variable; 
typedef  DevicelD  TFDevicelD; 

//  CreateTable:  return  a  table  objeet  of  the  given  type  that  has  values 
//  for  the  given  device/variable  pairs  over  the  given  time  interval. 
TRENDTABLE  CreateTable  ( 

in  seqDevieeVariable  sdv, 
in  TimeStamp  startTime, 

in  TimeStamp  endTime, 

in  TrendTableType  tableType 

); 


//  GetSummary:  return  all  possible  variables  and  devices  for  which 
//  trend  data  is  available,  as  well  as  the  minimum  and  maximum 
//  timestamp  of  all  the  data.  This  operation  can  be  used  to  help 
//  deeide  what  parameters  to  give  to  CreateTable. 
void  GetSummary( 

out  sequenoe<TEMIBVariable>  vars, 
out  sequence<TEDeviceID>  devices, 
out  TimeStamp  minTime, 
out  TimeStamp  maxTime 
); 
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22.3.7.Trend  Subscription  API 

The  Trend  Subscription  or  Trend  PASS  API  consists  of  two  operations  and  a  distribution 
or  update  policy.  The  operations  include  a  read  operation  that  posts  a  read  request  via  the 
PASSREADER  library  and  a  write  operation  that  writes  via  the  PASS  WRITER. 
Distribution  policy  for  individual  TrendTable  records  is  only  to  write  a  new  TrendTable 
record  if  the  incoming  TrendTable  record  value  is  new  or  different .  TrendTable  record 
information  is  only  given  to  readers  if  they  are  newly  created  (and  hence  have  not  seen  any 
of  the  data  yet)  or  if  the  reader  is  already  up  but  there  is  a  newly  written  TrendTable  record 
value.  Furthermore,  the  TrendTable  records  may  be  declared  persistent;  if  the  server 
crashes  and  restarts,  subsequently  registered  PASSREADERs  will  get  all  of  the  current 
records  (per  the  previous  rule). 

22.3. 7.1.  Trend  Subscription  PASSREADER 

The  Trend  Subscription  PASSREADER  is  a  library  object  that  embodies  the  read 
distribution  policy  for  TrendTable  record  information—  it  reads  any  changed  TrendTable 
records. 

22.3. 7.2. Trend Subscription  PASSWRITER 

The  Trend  Subscription  PASSWRITER  is  also  a  library  object  that  embodies  the  write 
distribution  policy  for  TrendTable  record  information— it  detects  any  changed  TrendTable 
records  and  writes  them  into  the  TrendPASS. 

22. 3. 7. 3.  TREND  PASS  IDL 

In  the  standard  PASS  IDL  file  pass.idl ,  and  using  the  standard  CORE  A  IDL  mechanism, 
#include  “Trend  PASS.idl”,  add  the  following  Trend  Subscription  refinements  as  stored 
in  the  file  Trend  PASS.idl 

#defme  PAYED AD  STRUCT 
struct  TREND_SUBSCRIPTION_REP  { 
string  DevName; 
string  VarName; 
string  VarValue  ; 

TimeStamp  startTime; 

TimeStamp  endTime; 
string  HeartBeat; 

}; 


#defme  PAYLOAD  REP  TREND  SUBSCRIPTION  REP 

#defme  PAYLOAD  TREND  SUBSCRIPTION 

#defme  PAYLOAD  PASS  TREND  SUBSCRIPTION  PASS 

//  The  following  pass-template  IDL  is  described  in  the  section  PASS  Template  IDL 

#include  “pass-tmpl.idl” 

22.4.  Attribute  Snapshots 

Getting  the  latest  value  of  a  shared  managed  object’s  attribute  is  often  useless  without 
context,  but  acquiring  the  current  value  and  acquiring  the  context  are  modeled  here  as  two 


76 


separate  jargons.  Applieations  are  expeeted  to  determine  what  an  appropriate  historieal 
eontext  is  and  request  it  either  via  a  bulk  transfer  or  start  eolleeting  via  a  subseribed-to 
transfer  or  some  eombination.  In  parallel,  they  should  request  the  eurrent  value,  and  when 
results  from  both  kinds  of  operations  are  in  hand,  the  applieation  can  then  display,  analyze 
or  store  them  as  needed. 

Requesting  the  current  value  of  a  Direct  Shared  Managed  Object  is  simply  a  matter  of 
invoking  the  GET  method  on  the  attribute  in  question. 

22.5.  Control  Commands 

Control  commands  will  be  forwarded  by  shared  managed  objects  to  the  responsible  peer 
management  system  to  be  executed  as  though  they  were  local.  Attempting  to  bypass  the 
forwarding  process  to  issue  control  commands  directly  to  the  target  object  is  strongly 
discouraged  for  two  reasons.  First,  it  may  bypass  security  mechanisms  that  implement 
authorization  delegation.  This  may  not  only  prevent  access  due  to  missing  authorization 
tokens  but  may  also  bypass  operations  coordination  mechanisms  resulting  in  a  control  tug- 
of-war  and  denial  of  service. 

Control  results  will  be  published  via  events  and  status  updates.  Direct  Shared  Managed 
Objects  generally  use  a  simple  write  such  as  SNMP  or  CORE  A  SET  method  on  the 
appropriate  attribute  to  implement  control,  but  if  a  non-SNMP  interface  is  expected,  other 
methods  may  be  defined  and  used. 

22. 5.1. Control  IDL 

The  control  jargon  interface  is  defined  in  the  following  IDE.  The  included  file 
nmtypes  .  idl  is  used  by  those  jargons  that  find  it  easiest  to  define  their  wrapper 
interfaces  in  terms  of  SNMP  MIBs.  It  is  defined  in  section  22.3.4,  Common  Trend 
Datatypes. 


//  Declared  types 

//  Each  call  processes  1  set  command  which  will  have  a  few  parameters 
//  a  MIB  variable,  a  MIB  value  for  the  variable,  and  a  destination  host. 

#include  "nmtypes . idl" 

interface  CONTROL  { 


exception  no_dev_or_oid{ } ; 

//  set  takes  a  host  ip  address,  a  snmp  object  identifier 

//  (old) ,  a  value  to  be  set  for  the  old,  calls  the  server  and  returns 

//  the  result  in  output  string  variable  res. 


void  set (  in  DevicelD 
in  MIBVariable 
in  MIBValue 
in  string 


dest_host,  //  seq  of  octet 
old,  //  seq  of  ulong 

val,  //  double 

community  name,  //  community 


name 


out  string 


res 


//  typedefs  for  downloadFrSvr ( ) ;  It  gets  around  Corbus  limitations 
//  copied  from  trend. idl  (TFMIBVariable  and  TFDevicelD) . 

typedef  DevicelD  CJDevicelD; 

typedef  MIBVariable  CJMIBOID; 

typedef  sequence<C JDeviceID>  seqDevices; 

typedef  sequence<C JMIBOID>  seqOIDs; 

//  downloadFrSvr  downloads  the  managed-hosts  list  and  the  oids 

void  downloadFrSvr (  out  seqOIDs  vars, 
out  seqDevices  devices 
)  raises  (  no_dev_or_oid  ) ; 

}; 


22.6.  Event  Monitoring 

Events  will  be  direeted  to  shared  event  eolleetions  whieh  will  forward  them  to  interested 
subseribing  peer  management  systems. 

The  Event  or  Event  PASS  API  eonsists  of  two  operations  and  a  distribution  or  update 
poliey.  The  operations  inelude  a  read  operation  that  posts  a  read  request  via  the 
PASSREADER  library  and  a  write  operation,  whieh  writes  via  the  PASS  WRITER. 
Distribution  poliey  for  individual  Event  messages  is  only  to  write  a  new  Event  message  if 
the  ineoming  Event  message  value  is  new  or  different .  Event  message  information  is  only 
given  to  readers  if  they  are  newly  ereated  (and  henee  have  not  seen  any  of  the  data  yet)  or 
if  the  reader  is  already  up  but  there  is  a  newly  written  Event  message.  Eurthermore,  the 
Event  messages  may  be  declared  persistent;  if  the  server  crashes  and  restarts,  subsequently 
registered  PASSReaders  will  get  all  of  the  current  records  (per  the  previous  rule). 

22.6.1.  Event  PASSREADER 

The  Event  PASSREADER  is  a  library  object  that  embodies  the  read  distribution  policy  for 
Event  message  information. 

22.6.2. Event  PASSWRITER 

The  Event  PASSWRITER  is  also  a  library  object  that  embodies  the  write  distribution 
policy  for  Event  message  information. 

22.6.3. EVENT_PASS  IDL 

In  the  standard  PASS  IDE  file  pass.idl ,  and  using  the  standard  CORE  A  IDE  mechanism, 
#include  “Event  PASS.idl”,  add  the  following  Event  refinements  as  stored  in  the  file 
Event_PASS.  idl 
#defme  PAYEOAD  STRUCT 
struct  EVENT_REP  { 
string  RecName; 
string  Rec Value; 
string  HeartBeat; 
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#define  PAYLOAD  REP  EVENT  REP 

#define  PAYEOAD  EVENT 

#define  PAYEOAD_PASS  EVENT_PASS 

//  The  following  pass-template  IDE  is  deseribed  in  the  seetion  PASS  Template  IDE 
#include  “pass-tmpl.idl” 

22.7.  Collateral  Service  Interfaces 

22. 7.1.  Directory  Services 

Direetory  services  will  be  imported  from  all  peer  management  systems  and  from  the  jargon 
ORB.  This  will  enable  management  applications  to  locate  Shared  Managed  Objects  and 
Peer  Management  System  Components. 

22.7.2. Time  Service 

Time  services  will  be  imported  from  the  local  peer  management  system.  Synchronization 
with  other  peer  management  systems  will  be  automatic  if  they  are  all  using  the  same 
distributed  time  service  and  manual  (by  communications  with  the  remote  Point  of  Contact) 
otherwise. 

22.7.3.Security  Services 

Authentication  and  privacy  services  will  be  imported  from  the  associated  security  project. 
Authorization  will  be  imported  from  the  peer  management  systems  and  the  jargon  ORB. 

22.7.4.Management  Services 

Management  Services  for  the  local  part  of  a  Shared  Managed  Object  will  be  imported  from 
the  local  peer  management  system.  Management  services  for  the  CORBA-based  jargon 
components  of  a  Shared  Managed  Object  will  be  imported  from  the  ORB.  Management 
services  for  the  jargon  wrapper  components  and  for  coordinated  jargon  management  will 
be  provided.  A  unified  graphic  user  interface  will  be  used  to  combine  access  to  and 
coordinate  usage  of  these  management  services  wherever  reasonable.  The  structure  of  the 
management  services  so  provided  is  defined  below  in  the  System  Component  Description 
section  on  Jargon  Management. 

In  addition  to  providing  jargon  configuration  and  GUI  monitoring,  PASS-based  jargons 
may  also  define  a  heartbeat  attribute  in  their  payloads.  The  heartbeat  is  updated  by  the 
PASSWriter  on  a  periodic  basis  and  can  be  used  by  the  PASSReaders  to  feed  status  to  a 
jargon  managed  object  on  the  management  system  importing  data  via  that  jargon.  If  the 
ultimate  source  (for  example  a  remote  poller)  goes  down  but  not  the  PASSWriter,  this  can 
be  used  to  signal  the  problem  across  a  distribution  interface  that  only  transmits  changed 
values  such  as  many  PASS  configurations  do.  In  addition,  PASSReaders  may  signal 
problems  (such  as  the  PASS  object  or  service  going  away)  directly  to  a  jargon  managed 
object. 

To  efficiently  support  collective  SMO  data  such  as  status  or  events  jargon  wrappers  may 
offer  various  multiplexing  services  by  sharing  a  single  PASS  jargon  instance  across 


multiple  target  shared  managed  objects.  The  sharing  may  be  implemented  either  by  using 
multiple  writers  to  feed  the  distribution  object  or  by  multiplexing  inputs  and  feeding  a 
single  writer,  or  both.  Multiple  writers  are  useful  if  several  systems  are  acting  jointly  as  a 
single  peer.  The  first  system  starts  up  the  jargon  instance,  the  others  then  join  in  as 
subsidiary  writers.  A  single  writer  is  more  efficient  if  a  single  system  is  serving  as  the 
liaison  system  and  can,  in  its  PASS  Writer,  scan  the  list  of  SMOs  (either  in  the  platform  or 
internally)  and  multiplex  the  necessary  inputs.  These  policies  may  be  stored  in 
environmental  attributes,  startup  command  line  arguments  or  in  the  SMO  Share  operation 
implementation. 

22.7.5.Persistent  Storage  Services 

Persistent  Storage  Services  will  be  imported  from  the  source  peer  management  system 
where  appropriate,  and  from  the  jargon  ORB  if  appropriate.  Persistent  Storage  includes 
but  is  not  confined  to  relational  databases,  object-oriented  databases  and  flat  files.  Usage 
of  persistent  storage  by  a  jargon  may  be  determined  by  local  policy,  in  which  case 
appropriate  configuration  switches  should  be  provided. 

22.8.  User  Interfaces 

User  interfaces  will  follow  the  style  of  the  associated  local  peer  management  system  as  far 
as  possible.  When  peer  system  GUI  support  is  missing,  X  windows  compatible  application 
interfaces  will  be  supplied  based  on  Tcl/tk.  Tcl/tk  scripts,  in  conjunction  with  the  Tcl/tk 
interpreter  (wish)  binaries  which  have  been  extended  to  provide  access  to  necessary 
CORBA  and  information  management  system  interfaces,  will  be  invoke-able  from  the 
information  management  system’s  native  GUI.  The  Tcl/tk  scripts  will  be  integrated  using 
the  information  management  system’s  GUI  integration  tools. 

23.  System  Component  Description 

The  System  Component  Description  focuses  on  a  low  level  detail  description  of  the 
underlying  implementation  object  model  used  to  support  the  functionality  described  in  the 
Functional  Component  Description  .  All  component  types  and  object  classes  are 
introduced  and  discussed  and  some  level  of  detail  is  included  to  describe  the  critical  sub¬ 
components  of  each. 

This  architecture  relies  on  categorizing  structured  management  information  such  as  MIB 
data  and  logs  according  to  their  distribution  requirements  as  discussed  in  the  previous 
sections.  In  the  resulting  implementations  each  jargon  consists  of  one  or  more  code 
objects,  both  CORBA  objects  and  undistributed  C++  objects.  The  simple  J/rect  jargon 
objects  are  used  for  stable,  low-volume  information,  synchronously  transferred  on  demand 
from  the  management  system.  The  attribute-snapshot  and  control  commands,  which  are 
based  on  synchronous  GET  and  SET  operations  to  managed  devices,  are  implemented  as 
direct  object  attributes  ’  IDE-generated  GETs  and  SETs. 

When  information  changes  often  enough  or  is  big  enough  (or  both)  that  implementing  it  in 
a  Direct  object  would  be  too  bandwidth- intensive  or  prone  to  hanging  due  to  blocking,  it  is 
instead  implemented  using  a  PASS  or  indirect  object,  which  allows  an  application  to 

subscribe  to  a  ongoing  service.  If  necessary  for  efficiency,  the  jargon  may  only  distribute 


80 


the  latest  ehanges.  PASS  objects  are  defined  by  a  templatized  IDL  that  specifies  the 

transport. 

There  are  six  jargons  for  network  device  management  information  and  functions: 

1 .  The  Status  jargon,  a  PASS  interface  to  status  information,  is  used  for  bandwidth 
efficient  monitoring. 

2.  The  Trend  jargon  interface  is  used  for  bandwidth  efficient  transfer  of  large  stable 
datasets  for  providing  trend  context. 

3.  The  Trend  Subscription,  a  PASS  interface,  is  used  for  bandwidth  efficient  transfer  of 
large  and  volatile  datasets  for  providing  trend  context. 

4.  The  Snapshot  ]diXgon  interface,  often  is  used  to  get  a  snapshot  of  the  value  of  a 
particular  attribute  to  be  combined  with  the  historical  context  supplied  by  one  of  the 
other  Trend  jargons. 

5.  The  Control  Command  jargon  allows  writing  directly  to  the  representation  of  the 
individual  managed  objects’  stable  attributes. 

6.  The  Event  jargon  is  a  PASS  interface  to  the  traps,  events  and  other  asynchronous 
notifications. 


As  far  as  component  implementation  goes,  the  platform  interface  and  translation  functions 
(a.k.a.  ‘wrapper  functions’)  may  be  a  part  of  either  the  server  operations  module  (in  the 
case  of  Direct  IDL  jargons)  or  the  Reader  and  Writer  modules  (in  the  case  of  a  PASS- 
based  jargon).  The  wrappers  described  here  are  given  as  examples  of  the  kinds  of  platform 
integration  issues  and  potential  solutions  encountered. 

In  addition  to  the  jargons,  there  is  a  set  of  jargon  management  components  that  serve  to 
route  management  information  and  commands  to  and  from  jargons.  These  components 
consist  of ‘helper  applications’  integrated  into  the  local  and  remote  peer  information 
management  systems.  They  are  invoked  either  automatically  or  manually  (depending  on 
the  execution  architecture)  from  inside  the  peer  system.  Most  commonly,  the  synchronous 
functions  (such  as  Attribute  Snapshots  and  Control)  are  invoked  by  hand  from  a  GUI  menu 
or  other  command,  (or  occasionally  by  a  peer  system  automated  poller)  and  the 
asynchronous  functions  (such  as  Status  and  Events)  are  invoked  by  a  combination  of  peer 
system  notification  handlers. 

If  the  peer  system  itself  offers  a  CORBA-compliant  interface,  these  functions  can  be 
incorporated  into  the  shared  managed  object  as  a  set  of  standard  Object  Eactory  methods 
(CreateJargon,  Destroy  Jargon,  BrowseCurrent  Jargons)  and  as  ORB  service  installation 
functions  (RegisterJargonTypes,  InstallJargonService).  The  specifics  of  the  Object  Eactory 
and  service  installation  are  dependent  on  the  ORB  being  used. 

If  there  is  no  CORBA  ORB  interface  or  it  is  not  available  for  a  particular  platform,  an 
auxiliary  ORB,  Corbus,  is  provided  and  its  management  API  is  installed  as  an  external 
application  on  the  peer  information  management  system.  The  standard  jargon  management 
attributes  described  in  the  system  interface  section  above  appear  as  the  user-visible 
application  interface. 
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23.1.  Status  Transfer 

Shared  managed  objeets  that  wish  to  export  status  information  need  to  ereate  a 
STATUS  PASS  Writer,  whieh  will  in  turn  loeate  or,  if  needed,  ereate  a  STATUS_PASS 
instanee  in  the  ORB.  The  STATUS  PASS  Writer  writes  status  updates  to  the 
STATUS  PASS  instanee  and  STATUS  PASS  Readers  who  have  subseribed  will  be 
notified. 

23.1.1.STATUS_PASS 

The  STATUS  PASS  elient  library  and  STATUS  PASS  server  skeleton  are  generated  by 
the  STATUS  PASS  IDL.  The  server  operations  skeleton  file  then  is  modified  to 
implement  the  STATUS  PASS  server  funetions.  Additional  payload  speeifie  files  define 
status  payload  utility  funetions. 

23.1.2.STATUS_PASS  Writer 

When  a  status  snapshot  is  available  (either  synehronously,  thanks  to  a  loeal  polling 
meehanism,  or  asynehronously  beeause  of  a  loeal  status  notifieation  meehanism)  it  is 
written  via  a  S_P  Writer  funetion.  If  the  value  is  different  from  the  previous  one,  it  is 
passed  on  through  the  STATUS_PASS  instanee  to  the  STATUS_PASS  Reader. 

If  the  Status  values  must  be  translated  or  mapped  to  a  standard  value,  translator  libraries 
may  be  linked  in.  They  are  invoked  automatically  via  the  Translate  function.  Developers 
may  specify  a  Null  or  NO-OP  library  that  does  no  translation  or  reformatting. 

23.1.3.STATUS_PASS  Reader 

STATUS_PASS  Reader  clients  use  a  library  to  subscribe  to  Status  information  updates. 

If  the  Status  values  must  be  translated  or  mapped  to  a  standard  value,  translator  libraries 
may  be  linked  in.  They  are  invoked  automatically  via  the  Translate  function.  Developers 
may  specify  a  Null  or  NO-OP  library  that  does  no  translation  or  reformatting. 

23.1.4. TME  Unwrapper 

Status  input  to  TME  is  defined  by  the  Status  Jargon  Management  interface  (see  SMO)  on 
the  ManagedNode  or  Collection  via  the  Import  switch,  which  when  Share  is  invoked  starts 
the  reader  client.  Status  is  displayed  by  association  with  particular  resource  icons  and 
colors  which  are  invoked  by  the  TME  wputstate  command.  No  other  display  is  needed 
because  TME  relies  heavily  on  the  GUI  symbol  to  implement  both  managed  objects  and 
collections  of  managed  objects. 

23.1.5. HPOV  Wrapper 

The  SMOViewer  Export  switch  uses  PlPLateStart  to  invoke  the  writer  client.  A  first  scan 
of  the  HPOV  database  (which  is  how  HPOV  implements  collections)  collects  SMOs  from 
the  set  of  all  MOs  and  creates  the  SMOEist  collection.  Subsequent  scans  use  the  SMOList 
to  collect  status  data  from  SMOs  and  feed  them  to  the  writer  client. 

23.1.6. HPOV  Unwrapper 

Status  input  to  HP  OpenView  is  defined  by  Status  Jargon  Management  on  a  Managed 
Object  via  the  Import  switch,  which  starts  the  reader  client  when  Share  is  invoked.  Status 
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is  displayed  by  association  with  particular  resource  icons  and  colors,  because  HPOV,  like 
TME,  relies  heavily  on  the  GUI  symbol  to  implement  individual  managed  objects. 

23.1. 7.TME  Wrapper 

The  SMO Viewer  Export  switch  starts  (if  needed)  the  writer  client  when  Share  is  invoked 
and  adds  the  shared  managed  object  to  the  writer  client  process’  SMOEist. 

23. 2.  Trend  /  Historical  Context  Bulk  Transfer 

The  Trend  Bulk  Jargon  is  a  Direct  IDE  jargon  that  synchronously  transfers  Historical 
Context  data.  To  transfer  trend  information,  clients  direct  the  Trend  server  to  create 
TrendTable  objects,  which  can  then  be  queried  for  the  desired  trend  information. 

The  synchronization  of  data  between  a  TrendTable  and  the  actual  data  available  from  the 
management  platform  can  be  accomplished  in  several  ways.  At  one  extreme,  the 
TrendTable  may  be  populated  upon  creation  and  never  updated.  At  the  other  extreme,  the 
TrendTable  may  never  actually  be  populated;  every  request  for  data  goes  all  the  way  back 
to  the  management  system.  Between  these  extremes,  the  TrendTable  may  be  demand- 
populated  and  refreshed  whenever  the  management  platform  has  additional  data,  like  a 
traditional  cache.  The  choice  of  strategy  depends  on  a  variety  of  factors  such  as  storage 
requirements  and  the  interfaces  available  for  extracting  trend  information  from  the 
management  platform. 

23.2.1.  TME  Unwrapper 

The  Policy  Region  menu  bar  is  extended  with  the  addition  of  the  P2P  menu.  The  Trend 
item  in  this  menu  launches  a  GUI  which  allows  the  user  to  select  trend  information  to 
import  from  a  remote  management  platform.  When  the  trend  information  is  received,  the 
information  is  written  to  a  file  in  the  TME  Brief  (one-line)  format,  and  a  disabled  monitor 
is  added  which  points  to  the  file. 

23.2.2. HPOV  Wrapper 

The  trend  server  functions  as  the  wrapper  for  both  HPOV  and  TME.  The  server 
determines  at  run  time  which  platform  it  is  running  with.  If  it  is  HPOV,  the  server  scans 
the  directory  given  by  $OV_DB/snmpCollect,  where  $OV_DB  is  an  environment  variable 
defined  by  OpenView,  and  makes  all  of  the  trend  information  found  there  available  to 
clients.  HP  OpenView’s  Trend  information  collector,  snmpCollect,  is  manually  started  as 
an  independent  application,  and  populates  the  $OV_DB/snmpCollect  directory. 

23.2.3. HPOV  Unwrapper 

The  OpenView  menu  bar  is  extended  with  the  addition  of  the  P2P  menu.  The  Trend  item 
in  this  menu  launches  a  GUI  which  allows  the  user  to  select  trend  information  to  import 
from  a  remote  management  platform.  When  the  trend  information  is  received,  the 
information  is  written  to  a  file  in  a  subdirectory  under  $OV_DB/snmpCollect  (see  above). 

23.2.4. TME  Wrapper 

The  trend  server  functions  as  the  wrapper  for  both  HPOV  and  TME.  The  server 
determines  at  run  time  which  platform  it  is  running  with.  If  it  is  TME,  the  server  executes 
a  series  of  TME  commands  (wlsmon  and  wlookup)  to  locate  all  of  the  SNMP  User- 
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Defined  Numeric  monitors,  and  makes  all  of  the  trend  information  found  there  available  to 
clients.  The  user  must  set  up  SNMP  monitors  separately  with  Tivoli’s  Sentry/Distributed 
Monitoring  product. 

23.3.  Trend  /  Historical  Context  Subscription  Transfer 

The  Trend  Subscription  service  is  also  known  as  the  TrendPass  service,  from  its 
component  names. 

23.3.1.  TREND_PASS 

NOTE:  The  TREND  PASS  service  has  not  yet  been  implemented. 

The  TREND  PASS  client  library  and  TREND  PASS  server  skeleton  are  generated  by  the 
TREND  PASS  IDE.  The  server  operations  skeleton  file  is  then  modified  to  fully 
implement  the  server  functions.  Additional  payload  specific  files  define  trend  payload 
utility  functions. 

23.3.2. TREND_PASS  Writer 

When  a  TrendTable  entry  snapshot  is  available,  it  is  written  via  a  TREND  PASS  Writer 
function.  If  the  value  is  different  from  the  previous  one,  it  is  passed  on  through  the 
TREND_PASS  instance  to  the  TREND_PASS  Reader. 

If  the  TrendTable  values  must  be  translated  or  mapped  to  a  standard  value,  translator 
libraries  may  be  linked  in.  They  are  invoked  automatically  via  the  Translate  function. 
Developers  may  specify  a  Null  or  NO-OP  library,  which  does  no  translation  or 
reformatting 

23.3.3. TREND_PASS  Reader 

TREND_PASS  Reader  clients  use  a  library  to  subscribe  to  TrendTable  entry  information 
updates. 

If  the  TrendTable  entry  values  must  be  translated  or  mapped  to  a  standard  value,  translator 
libraries  may  be  linked  in.  They  are  invoked  automatically  via  the  Translate  function. 
Developers  may  specify  a  Null  or  NO-OP  library,  which  does  no  translation  or 
reformatting. 

23.3.4. TME  Unwrapper 

TrendSubscription  input  to  TME  is  defined  by  the  TrendSubscription  Jargon  Management 
(see  SMOViewer)  as  either  ManagedNode  or  Collection  extension  attribute.  TrendTables 
are  populated  when  a  Share  invoke  sees  the  Import  switch  and  starts  the  process  of 
subscribing,  creates  a  local  TrendTable  and  starts  the  TREND  PASSREADER  . 
TrendTables  are  made  visible  via  a  TME  Collection  Menu  hook  plus  tk  windows 
application  TrendViewer. 

23.3.5. HPOV  Wrapper 

HP  OpenView's  Trend  information  collector,  snmpCollect,  is  manually  started  as  an 
independent  application.  It  is  manually  configured  to  collect  from  SMOs  by  the 
SMOViewer  Export  switch  and  the  wrapper  tracks  the  collection  by  monitoring  collection 
files  when  Share  is  invoked. 
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23.3.6. HPOV  Unwrapper 

TrendSubscription  input  to  HP  OpenView  is  defined  by  the  TrendBulk  Jargon 
Management  on  a  managed  object  via  the  Import  command,  which  starts  the  reader  client 
via  HPLateStart.  Trend! ables  are  made  visible  via  a  toplevel  OV  installed  tk  windows 
TrendViewer  application. 

23.3.7. TME  Wrapper 

The  Trend  Jargon  Management’s  Export  command  starts  an  external  application 
formatting  of  collection  information  previously  configured  (by  the  TME  Collection 
configuration  API). 

23.4.  Basic  Shared  Managed  Object  Attribute  Snapshot 

Attribute  Snapshots  use  the  CORBA  standard  IDE  primitive  attribute  to  define  a 
synchronous  GET  function  for  each  attribute  whose  value  is  to  be  collected  for  a  shared 
managed  object. 

23.4.1.  TME  Unwrapper 

The  Snapshot  Jargon  Management  (see  SMOViewer)  defines  attribute  snapshot  input  to 
TME  as  a  Collection  extension  attribute.  Attribute  display  structures  are  populated  by  the 
Import  switch,  which  starts  the  remote  collection  process  when  Share  is  invoked. 
Attributes  are  made  visible  via  a  TME  Collection  Menu  hook,  plus  a  tk  windows 
application  MIB  Browser  known  as  SnapshotViewer. 

23.4.2. HPOV  Wrapper 

The  SMOViewer  Export  switch  uses  the  HP  OpenView  application  startup  function 
HPLateStart  to  invoke  the  writer  client  when  Share  is  invoked.  A  first  scan  of  the  HPOV 
database  collects  SMOs  from  the  set  of  all  MOs  and  creates  the  SMOEist.  Subsequent 
scans  use  the  SMOEist  to  collect  attribute  data  from  SMOs  and  feed  them  to  the  writer 
client. 

23.4.3. HPOV  Unwrapper 

The  Snapshot  Jargon  Management  defines  input  to  HP  OpenView.  Snapshot  viewer  is  an 
external  installed  tk  windows  application  which  reads  SMOEist  and  collects  MIB  data 
from  the  Snapshot  reader  client  for  each  SMO  (does  not  update  OV  database  for  that 
SMO). 

23.4.4. TME  Wrapper 

The  SMOViewer  Export  switch  starts  (if  needed)  and  adds  the  shared  managed  object  to 
the  writer  client  process  when  Share  is  invoked.  The  writer  client  scans  all  the  SMOs  in 
the  SMOEist. 

23.5.  Basic  Shared  Managed  Object  Attribute  Controi 

Attribute  Snapshots  use  the  CORBA  standard  IDE  primitive  attribute  with  the  option 
read-write  to  define  a  synchronous  SET  function  for  each  attribute  whose  value  is  to  be 
controlled  on  a  shared  managed  object. 
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23.5.1. TME  Unwrapper 

The  Control  Jargon  Management  (see  SMOViewer)  defines  eontrol  interfaees  as  a 

ManagedNode  extension  attribute.  Current  values  are  first  populated  by  a  legacy 
callback  on  the  appropriate  Sentry  Collection;  the  Control  operation  result  is  used  to 
update  the  display.  The  display  itself  is  implemented  via  a  ManagedNode  hook  plus  a  tk 
windows  application  which  is  a  variant  of  the  SnapshotViewer. 

23.5.2. HPOV  Wrapper 

The  SMOViewer  Export  switch  uses  HPLateStart  to  start  the  server  when  Share  is 
invoked.  A  first  scan  of  the  HPOV  database  collects  SMOs  from  the  set  of  all  MOs  and 
creates  the  SMOList.  Subsequent  scans  use  the  SMOList  to  collect  attribute  data  from 
SMOs  for  initial  value  setting.  SET  requests  are  handled  as  they  arrive. 

23.5.3. HPOV  Unwrapper 

The  Control  Jargon  Management  defines  input  to  HP  OpenView.  The  Control  viewer  is  a 
variant  of  the  Snapshot  viewer  with  writing  (SETs)  enabled. 

23.5.4. TME  Wrapper 

The  SMOViewer  Export  switch  starts  (if  needed)  and  adds  the  shared  managed  objects  to 
the  writer  client  process  when  Share  is  invoked.  The  writer  client  scans  all  the  SMOs  in 
the  SMOEist  with  Control  enabled. 

23.6.  Event  Forwarding 

NOTE:  Event  Eorwarding  has  not  yet  been  implemented. 

Shared  managed  objects  that  wish  to  export  status  information  need  to  create  a 
STATUS  PASS  Writer,  which  will  in  turn  create  a  STATUS_PASS  instance.  Status 
updates  are  written  to  the  STATUS_PASS  instance  and  STATUS  PASS  Readers  who 
have  subscribed  will  be  notified. 

23.6.1.  EVENT_PASS 

The  EVENT_PASS  client  library  and  EVENT  PASS  server  skeleton  file  are  generated  by 
the  EVENT  PASS  IDE.  The  server  operations  skeleton  file  is  then  modified  to  fully 
implement  the  server  functions. 

23.6.2. EVENT_PASS  Writer 

When  an  event  is  available,  it  is  written  via  an  EVENT  PASS  Writer  function. 

In  the  case  of  events,  the  value  is  always  different  from  the  previous  one,  so  it  is  passed  on 
through  the  EVENT  PASS  instance  to  the  EVENT  PASS  Reader. 

If  the  events  must  be  translated  or  mapped  to  a  standard  format,  translator  libraries  may  be 
linked  in.  They  are  invoked  automatically  via  the  Translate  function.  Developers  may 
specify  a  Null  or  NO-OP  library,  which  does  no  translation  or  reformatting. 

23.6.3. EVENT_PASS  Reader 

EVENT  PASS  Reader  clients  use  a  library  to  subscribe  to  Events. 
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If  the  events  must  be  translated  or  mapped  to  a  standard  format,  translator  libraries  may  be 
linked  in.  They  are  invoked  automatieally  via  the  Translate  funetion.  Developers  may 
speeify  a  Null  or  NO-OP  library,  whieh  does  no  translation  or  reformatting. 

23.6.4. TME  Unwrapper 

Input  to  TME  is  defined  in  Enterprise  Console  Event  handling  or  in  SMO Viewer  as  a 
ManagedNode  extension  attribute  EventEog  whieh  is  populated  by  the  Import  switch 
starting,  when  Share  is  invoked,  a  legacy  callback  logfile  writer  and  an  EVENT_PASS 
reader  client.  The  event  logs  are  visible  via  a  ManagedNode  menu  hook  plus  a  tk  windows 
application  EventEogViewer  or  by  forwarding  to  EnterpriseConsole. 

23.6.5. HPOV  Wrapper 

The  SMO  Viewer  Export  switch,  when  Share  is  invoked,  uses  HPLateStart  to  invoke  the 
writer  client.  A  first  scan  of  the  HPOV  database  collects  SMOs  from  the  set  of  all  MOs 
and  creates  the  SMOEist.  Subsequent  scans  use  the  SMOEist  to  setup  event  forwarding 
from  SMOs  and  feed  them  to  the  write. 

23.6.6. HPOV  Unwrapper 

Input  to  HP  OpenView  is  defined  by  the  Event  Jargon  Management,  which  uses  the  Import 
switch  and  the  Share  function  to  start  the  Event  reader  client.  The  EventViewer  is  an 
external  installed  tk  windows  application  which  accepts  event  data  from  members  of  the 
SMOEist 

23.6.7. TME  Wrapper 

The  SMOViewer  Export  switch  and  the  Share  function  start  (if  needed)  and  add  the  M.O. 
to  the  writer  client  process  which  covers  all  the  SMOs  in  the  SMOEist  with  event 
forwarding  enabled. 

23.7.  Jargon  Management 

The  normally  visible  Jargon  management  interfaces  consist  of  managing  the  the  Shared 
Managed  Objects,  the  local  Managed  Objects  and  Collections  on  which  they  are  based,  the 
local  representations  of  the  remote  Peer  Managers  which  have  custody,  and  the  connecting 
Jargons.  Eor  the  most  part,  the  operators  deal  with  the  Share/Unshare  functions,  which 
create/destroy  a  SMO.  All  the  other  operations  are  subsidiary. 

Access  to  the  SMO  and  Peer  Manager  interfaces  is  provided  by  P2P  Management  browsers 
and  control  GUIs  which  can  either  be  a  top-level  management  system  menu  item  (for 
shared  managed  objects  which  are  managed  as  collections)  or  can  be  attached  to  individual 
SMOs  when  they  require  individual  jargons. 

‘Under  the  hood’  Jargon  management  interfaces  implement  a  number  of  operations 
policies  such  as  updates-only  distribution,  writer  multiplexing  level,  persistent  storage 
usage,  and  security  level.  In  addition  they  coordinate  jargon  component  startup  and 
interactions  with  the  parent  platform  components  such  as  pollers  and  displays. 

Access  to  low-level  Jargon  management  interfaces  is  via  a  combination  of  environment 
variables,  command  line  arguments  and  a  monitoring  and  control  GUI  that  breaks  out  the 
individual  jargon  components. 
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24.  Appendices 

24. 1.  On-line  References 

•  Peer  to  Peer  System  Requirements  -reqs.html 

•  Network  Management  Study  -  nmfinal4.html 

•  Introduetion  to  Cronus  -  http://morpheus.bbn.oom/oronus_man/ 

•  Cronus  Operator  Manual  -  http://morpheus.bbn.oom/oronus_man/operman/oatl/ 

•  Cronus  User  Manual  -  http://morpheus.bbn.oom/oronus_man/userman/oatl/ 

•  Corbus  Operator’s  and  Installation  Manual  - 
http://www.bbn.oom/offerings/corbus/oorbusim.htm/ 

•  CORBA  2.0  Specification  -  http://www.omg.org/corba/corbiiop.htm 

•  standard  SNMP  MIB  definitions  -atommib.html 

•  standard  SNMP  MIB  definitions  -  lid-abstracts.html 

•  Odyssey  Research  Associates  -  http://www.oracorp.com/ 

•  SNMPIDL  -  http://www.smile.fr/us/prod.htm 

•  XBind  -  http://comet.ctr.columbia.edu/xbind/ 

24.2.  Glossary 

24.2.1.  Peer  to  Peer 

A  communications  model  that  allows  but  does  not  require  the  management  systems  to 
define  themselyes  as  subordinates  or  superiors  in  order  to  exchange  information  about  the 
managed  objects  in  their  domain. 

24.2.2. Jargon 

A  specialized  CORBA-based  communications  seryice  (and  associated  API)  that  translates 
and  distributes  management  information  about  shared  managed  objects  to  heterogeneous 
peer  management  systems  using  infrastructure  objects. 

24.2.3. Managed  Object 

A  deyice  or  component  whose  management  interface  is  defined  yia  an  object-oriented 
language  such  as  the  SNMP  MIB  definitions.  Also  known  as  a  Managed  Object  Class  or 
MOC. 

24.2.4. Managed  Object  Instance  or  MOI 

A  specific  instance  of  a  managed  object  class,  identified  by  a  fully  distinguished  name 
(system  or  node  name  plus  any  other  labels  that  will  enable  it  to  be  distinguished  from 
others  of  its  class. 
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24.2.5.Shared  Managed  Object 

A  distributed  managed  object,  responsibility  for  which  is  shared  among  peer  management 
systems.  It  is  defined  as  a  collection  of  jargons  that  form  an  association  from  a  local 
managed  object  to  the  custodial  set  of  remote  peer  management  systems. 

24.2.6.lnfrastructure  Object 

A  jargon  component  which  uses  object-oriented  technology,  often  CORBA-based,  to 
export  or  import  shared  managed  object  information.  There  are  two  main  classes  of 
infrastructure  objects:  distributed  objects,  which  are  CORBA-based,  and  local  objects, 
which  are  not  distributed  and  use  traditional  object  oriented  languages  and  techniques.  Of 
the  distributed  infrastructure  objects  there  are  two  types:  direct  or  synchronous 
request/response  objects  and  indirect  or  piecewise  asynchronous  service  (PASS)  objects. 

24.2. 7. Direct  Object 

A  collection  of  management  information  and  operations  from  a  shared  managed  object,  the 
API  to  which  is  directly  defined  by  CORBA IDL.  Since  CORBA  IDL  operations  are 
based  on  synchronous  RPC,  this  family  of  jargons  is  useful  only  for  occasional  information 
transfers.  Compare  with  Indirect  or  PASS  Object. 

24.2.8.lndirect  Object 

see  PASS  Object 

24.2.9. PASS  Object 

A  PASS  Object,  together  with  the  associated  reader  and  writer  wrappers,  allows  a  peer 
management  system  to  subscribe  to  an  update  service  which  only  distributes  the  latest 
changes  in  a  shared  managed  object.  PASS  objects  are  defined  by  a  templatized  IDL, 
which  specifies  the  transport  and  the  standard  transfer  datatype. 

24.2.10.  Collateral  Services 

A  set  of  services  which  can  be  defined  modularly  by  their  own  architectures  but  whose 
functions  provide  necessary  utilities  for  management  systems. 

24.2.1 1  .Authentication 

A  security  function  where  the  identities  of  the  source  and  occasionally  the  destination(s)  in 
an  information  transfer  are  checked,  usually  by  cryptographic  methods,  to  ensure  they  are 
the  source  and  destination(s)  intended. 

24.2.12.Authorization 

A  security  function  where  the  right  or  authority  of  the  requestor  to  request  an  operation  is 
checked,  usually  by  comparing  the  requestor’s  identity  to  an  access  control  set  or  by 
checking  a  permissions  token  included  with  the  request  for  validity. 

24.2.1  S.Integrity 

A  security  function  where  the  request,  response  or  notification  message  is  checked,  usually 
cryptographically,  to  detect  tampering. 
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24.2.14.Privacy 

A  security  function  where  isolation  or  encryption  prevent  interception  or  unauthorized 
reading  of  sensitive  request,  response  or  notification  messages. 

24.2.1  S.Replay  Attack 

An  attempt  to  fool  a  destination  into  accepting  as  genuine  a  request,  response  or 
notification  message  that  is  actually  a  stale  or  misleading  copy  of  an  earlier,  intercepted 
message. 

24.2.1 6. Denial  of  Service  Attack 

An  attempt  to  prevent  useful  work  or  communication  by  others  by  overloading  the  capacity 
of  some  resource.  Distinguished  from  simple  overload  by  the  hostile  intent  of  the  source. 

24.2.1 7. Persistent  Storage 

Keeping  information  on  disk  or  in  another  storage  medium,  which  will  survive  the  crash  or 
power  failure  of  the  peer  to  peer  system. 

24.2. 18.  Management  of  Management 

Also  known  by  its  acronym,  MOM,  the  recursive  application  of  standardized  management 
methods  to  the  management  systems  and  infrastructure.  As  bootstrapping  and  graceful 
shutdown  require  that  the  management  systems  work  before  most  network,  system  and 
collateral  services  infrastructure  is  up  and  when  they  are  down,  this  results  in  a  certain 
duplication  and  occasional  embedding  of  some  services  and  increased  overhead. 

24.2. 19.  Heartbeat 

A  management  of  management  function  in  which  communications  infrastructure  which  is 
only  occasionally  used  or  whose  traffic  is  sporadic  is  periodically  checked  to  see  if  it  is  up. 
The  period 

is  determined  by  trading  off  how  quickly  the  information  transferred  can  go  stale  against 
the  overhead  cost  of  using  the  channel  for  MOM  information. 

24.2.20. XBind 

The  ATM  interface  is  XBind,  a  CORBA  based  management  API  based  on  the  ATM 
signaling  interface  and  used  to  control  end  to  end  ATM  resources. 
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